date:20140424

On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
 On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com wrote:
 If you are
 a rare user who needs Bitcoin-Qt on an incompatible system you can at least
 build it from source.

 Tails users usually can't really build it from source— talks is a live
 boot mostly stateless linux distribution for privacy applications.
 It's really good in general.

Aside: But is Bitcoin Core a well-suited application for those uses? I
cannot imagine someone running a full node on a stateless system.

Anyhow: As this is only one symbol, we can probably get rid of it (as
we didn't use it in 0.8.6?), or put it behind some #ifdef
COMPATIBILITY_BUILD...

Another option: Instead of statically building it'd be easy enough to
build against the 4.6 Qt headers instead without even swapping the
library. Qt is, after all, forward-compatible - between the 4.x
versions. This will lose some GUI features but if compatibility is
more important here that's a choice that can be made.

Wladimir

--
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] Development Roadmap of Bitcoin Core 0.9.2

On Thu, Apr 24, 2014 at 10:02 AM, Wladimir laa...@gmail.com wrote:
 On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell gmaxw...@gmail.com wrote:
 On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com wrote:
 If you are
  Another option: Instead of statically building it'd be easy enough to
 build against the 4.6 Qt headers instead without even swapping the
 library. Qt is, after all, forward-compatible - between the 4.x
 versions. This will lose some GUI features but if compatibility is
 more important here that's a choice that can be made.

Are you sure this is Qt 4.6 at all? Not Qt 4.7?

I'd expect *much* more symbols if this was a Qt 4.8 versus 4.6
conflict. Qt 4.7 introduced a lot of new things (see all the
occurences of  #if QT_VERSION = 0x040700 - things like
setPlaceHolderText would be expected to pop up too), but 4.8 did not.

Can you check?

Wladimir

--
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] New BIP32 structure

Right. So part of this is my fault, I'm afraid, because I do not intend to
implement any kind of subwallet/account support in bitcoinj. My reasons are:

   1. The bitcoinj API already lets you create and use multiple wallets.
   What's more, because of the desire to do key rotation (think rotating a
   previously unencrypted wallet to an encrypted one that is stored on SSD's
   that cannot reliably erase data), a bitcoinj wallet can actually contain
   multiple BIP32 seeds and hierarchies at once, although only the last one
   will be used for vending addresses. So adding subwallet support onto this
   makes it even more complicated.

   2. If there was a much better user experience to be enabled by this, it
   may be worth it, but I believe many people will find subwallets rather
   confusing. They don't match the analogy of bank accounts in several ways.
   For instance, transferring money across them leaks private data and costs
   miners fees, neither of which are true with banks.

   Also it differs in a more important way. People have different bank
   accounts because those accounts implement different policies. Current
   accounts may pay a lower interest rate than savings accounts, but have
   different features, and accounts can be used as security boundaries i.e. no
   card withdrawals from savings. But subwallets are not like this. The only
   justification for their existence is to avoid outputs being merged together
   to make payments - a subtle technical detail of the protocol that users are
   ill equipped to understand. If someone asked me why should I create a
   second account I would be unable to give them a satisfying answer without
   first teaching them about how the Bitcoin protocol works and the privacy
   implications of that, which is practically a lecture sized topic.

   3. MultiBit did support multiple wallets for a long time (just by
   creating multiple wallet files and using the support in bitcoinj for
   running them in parallel), but they decided to remove this feature in
   MultiBit HD because it caused support headaches. People would stash money
   in one wallet or the other, close the wallet and then forget and think they
   had lost it, etc. It may be that TREZOR type subwallets don't suffer this
   confusion because they can't be moved around or closed in the same way a
   file can be, but still, this is a data point against multiple simultaneous
   wallets. At least for products targeting entry level consumers.

Whilst I can well believe there are TREZOR users who are asking for this
feature today, currently the costs feel a bit higher than the benefits.

It would be rather nice to be able to type in a mnemonic code that myTREZOR
was initialised with and duplicate that wallet into a bitcoinj based wallet
app. But if I have to implement subwallets and expose this in the API, and
if all wallet authors that want to be able to share a wallet with myTREZOR
have to expose subwallets in their GUIs too, even though the concept may
prove confusing and hard to explain, then it might be more tempting to just
tell users that want to switch wallet apps to send the money via the block
chain instead.




On Thu, Apr 24, 2014 at 9:10 AM, Pieter Wuille pieter.wui...@gmail.comwrote:

 On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin thoma...@gmx.de wrote:
  Why do clients need to use the features in BIP 64? If Electrum doesn't
 want to
  use accounts, [...]
 
  To clarify:
  Electrum plans to have bip32 accounts; Multibit will not, afaik.

 To clarify:
 BIP64 has a much stricter definition for accounts than BIP32.

 In BIP32, it is not well specified what accounts are used for. They
 can be used for subwallets, receive accounts (as in bitcoind's
 account feature), recurring payments, part of a chain used as
 multisig addresses, ... determined individually for each index.

 In BIP64, they are strictly used for subwallets, and can't be used by
 anything else.

 --
 Pieter


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

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

Re: [Bitcoin-development] Development Roadmap of Bitcoin Core 0.9.2

2014-04-24 Thread Warren Togami Jr.

On Wed, Apr 23, 2014 at 10:02 PM, Wladimir laa...@gmail.com wrote:

 On Thu, Apr 24, 2014 at 12:28 AM, Gregory Maxwell gmaxw...@gmail.com
 wrote:
  On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com
 wrote:
  If you are
  a rare user who needs Bitcoin-Qt on an incompatible system you can at
 least
  build it from source.
 
  Tails users usually can't really build it from source— talks is a live
  boot mostly stateless linux distribution for privacy applications.
  It's really good in general.

 Aside: But is Bitcoin Core a well-suited application for those uses? I
 cannot imagine someone running a full node on a stateless system.

 Anyhow: As this is only one symbol, we can probably get rid of it (as
 we didn't use it in 0.8.6?), or put it behind some #ifdef
 COMPATIBILITY_BUILD...

 Another option: Instead of statically building it'd be easy enough to
 build against the 4.6 Qt headers instead without even swapping the
 library. Qt is, after all, forward-compatible - between the 4.x
 versions. This will lose some GUI features but if compatibility is
 more important here that's a choice that can be made.

 Wladimir


I now see how it worked with Bitcoin 0.8.6.  Lucid has qt-4.6.2.

It is more than one symbol.  It does not seem to be a wise thing to replace
functions beyond the trivial in glibc and libstdc++.

I personally think we need to decide upon a cut-off point beyond which it
makes no sense to add the risk of increased complexity.  RHEL6 had qt-4.6.2
as well and I don't think I've heard a single complaint about bitcoin-qt
being broken there given almost nobody uses it as a desktop.

Warren
--
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] New BIP32 structure

2014-04-24 Thread Thomas Voegtlin



Le 24/04/2014 09:21, Gregory Maxwell a écrit :
 
 It doesn't appear to me that reoccurring payments, receive accounts,
 multisig addresses, etc can be used with this proposal, but instead
 you must use a different purpose code and another BIP and are not
 compatible with the draft here.
 
 Am I misunderstanding it?   Will Electrum be limiting itself in this
 way?  I'd consider it a unfortunate loss of functionality if wallets
 couldn't implement reoccurring payment chains without making users
 generate entirely different wallets (which they couldn't share funds
 across) since addresses for recurring payments was one of the main
 motivations in BIP32.
 
 

No, Electrum will not be limiting itself in this way. I believe that we
are only at the beginning of exploring the different possibilities
opened by HD wallets. It will probably take years until we have clear
ideas on what users need, what choices they make, and how to organize
everything. Therefore it is too early to take decisions that might limit
future functionality.

I can see that it is very difficult today to find a consensus on wallet
structure between wallet developers. In addition, I changed my mind
several times on these questions, so I guess I will probably need to
change things again in the future.

This is why I decided to include a version number in Electrum seeds. The
version number will be updated everytime the wallet structure changes. I
know many developers do not follow me on this, but that is something I
am quite sure Electrum needs, despite all the other things I am not sure
about :)

I think it is too early to aim for inter-wallet compatibility today. I
guess we should postpone this goal, and move on with software releases.
As Andreas pointed out, we should just make sure that we do not import
an incompatible seed in another wallet, because not recovering all your
bitcoins would be a terrible user experience; the version number built
in the seed will ensure that for Electrum.

--
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-24 Thread Gregory Maxwell

On Thu, Apr 24, 2014 at 12:58 AM, Mike Hearn m...@plan99.net wrote:
 The complexity overhead is trivial - we already used coinbase scriptSigs for
 voting on P2SH, I'm sure it'll be used for voting on other things in future
 too.

We use coinbase sigs to gauge the safety of enforcing a soft fork
several times and not just for P2SH, to determine when enforcement of
it will be decisive and not result in risking a partition in the
network that might permit transaction reversals. This is not voting.
As a feature decision mechanism his is a rather coercive thing because
it gives the highest hash-power bidders control even when their
interests may be rather thoroughly unaligned with population that owns
and uses bitcoin in general, but as a plain indicator of when its safe
to enforce a new rule (same mechanism, different motivation— though a
point is that safe usage means using much more than 50% as the
threshold) it works pretty well.

  that's hugely complex and messy.

Yes, making really distributed systems that work in a complex world is
hard. It certantly would be /easier/ to just declare miners trusted
parties and require them to always collude to produce a single
consensus view of the world that is always honest and never
contradictory, except that it doesn't work. Because they aren't
individually trusted or even trustworthy.

 Why? Remember deleting coinbases with nothing more than a simple majority is
 already possible in the existing protocol and always has been.

Temporarily censoring transactions by orphaning otherwise valid blocks
that contain them for as long as you retain a majority is possible and
impossible to prevent in this architecture. This isn't the same as
deleting.  Deleting suggests the common misconception that a majority
of miners can do anything they want.

--
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] Development Roadmap of Bitcoin Core 0.9.2

On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. wtog...@gmail.com wrote:

 I now see how it worked with Bitcoin 0.8.6.  Lucid has qt-4.6.2.

 It is more than one symbol.  It does not seem to be a wise thing to replace
 functions beyond the trivial in glibc and libstdc++.

Qt is not part of the compiler/build environment. Thus we don't need
to resort to those kind of tricks.

As I said: we can easily build against Qt 4.6 instead. As said, that
wouldn't even need building Qt on linux, just unpacking and exporting
the headers.

But indeed we need to decide on a cut-off point. I'd have preferred
4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010.
Apart from tails it doesn't seem like anyone is using those old stable
distributions on the desktop.

Wladimir

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

On Thu, Apr 24, 2014 at 10:19 AM, Gregory Maxwell gmaxw...@gmail.comwrote:

 This is not voting.


It absolutely is! It was widely discussed as such at the time, here is a
thread where people ask how to vote and the operator of Eclipse said he was
removing his vote for P2SH:

https://bitcointalk.org/index.php?topic=60937.0

You might not feel it's a particularly fair or representative vote, but
it's still miners saying I support enforcement of this new rule or I do
not support this where the majority of cast votes wins. Some miners have
more votes than others, but it's still a vote.


 Yes, making really distributed systems that work in a complex world is
 hard. It certantly would be /easier/ to just declare miners trusted
 parties


Miners *are* trusted parties, they are just not all trusted simultaneously.
Bitcoin can tolerate a small number of dishonest miners whilst producing a
degraded service. It cannot work if all miners are dishonest or decide to
deviate from their intended operation, like if they all produce empty
blocks. The white paper made this clear from the start, and it's also
common sense.

Allowing the majority of honest miners to keep the dishonest ones in check
is what Bitcoin is all about. I don't understand this view that a very
small change to the existing protocol is somehow terrible or impossible,
but expecting everyone to simply build an entirely new system from scratch
is easy and inevitable. I'd much prefer to just keep the existing system
working as well as it has so far, and I think that is true of most users
too.


 Temporarily censoring transactions by orphaning otherwise valid blocks
 that contain them for as long as you retain a majority is possible


No, coinbases are deletable. If some miners fork the chain and build a
longer one, the others will all switch to it and the coinbases blocks they
previously mined will never become spendable (effectively they were
deleted before maturity). Only if the other miners also blacklist the
majorities fork and never join it, then the majority for some reason gives
up and rejoins the minority, is what you described correct. But why would
they do that? If they're the majority then all the other nodes will follow
them. They have no incentive to throw away their fork and rejoin the
minority chain ever again.

I think the root of this disagreement is whether the block chain algorithm
left by Satoshi is somehow immutable and itself the end, or whether it's
(as I see it) just a means to an end and therefore an algorithm that can be
tweaked and improved, to get us closer to the goal.

If the end is a useful payments system, as decentralised as possible, that
prevents double spending, then this proposal is a simple enhancement of the
current system that ensures corrupt miners don't get paid by honest users
for services they didn't provide, thus discouraging a particular kind of
attack.
--
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-24 Thread Andy Parkins

On Wednesday 23 April 2014 15:31:38 Mike Hearn wrote:
  There _are_ consequences though: 95% of the time, you end up buying
  something and paying for it.
 
 Yeah, I was imagining a situation in which people who use Bitcoin regularly
 do buy things they actually want, but wouldn't say no to occasionally
 getting them for free (think coffees at starbucks etc). So if their double
 spend fails, no big deal, they're no worse off than if they didn't try.

Again true enough; but then we're back to evenly distributed dishonesty, and 
so you still don't get the potential 5% scam being used at 100% capacity.


Andy

-- 
Dr Andy Parkins
andypark...@gmail.com


--
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-24 Thread Gregory Maxwell

On Thu, Apr 24, 2014 at 1:39 AM, Mike Hearn m...@plan99.net wrote:
 It absolutely is!
 https://bitcointalk.org/index.php?topic=60937.0

May I direct your attention to the third post in that thread?

Luke attempting to ret-con the enforcement flag into a vote didn't
make it one, and certantly wouldn't make it a fair, just, or sane
method of one. And so much for the effectiveness— you didn't implement
it for years even after it was deployed.

And yes, you can take any decision system and draw comparisons to
voting and call it a vote but that doesn't mean is serves the same
role or was intended for that purpose.

 No, coinbases are deletable. If some miners fork the chain and build a
 longer one, the others will all switch to it and the coinbases blocks they

Yes, you can reorg out the blocks and actually remove them, but I
understood that you were _not_ proposing that quite specifically. But
instead proposed without reorging taking txouts that were previously
assigned to one party and simply assigning them to others.

 I think the root of this disagreement is whether the block chain algorithm
 left by Satoshi is somehow immutable and itself the end, or whether it's (as
 I see it) just a means to an end and therefore an algorithm that can be
 tweaked and improved, to get us closer to the goal.

I don't think thats the root of the the disagreement at all. I think
all sorts of changes are interesting, especially ones that increase
flexibility or fix bugs but less so ones that would impose significant
changes on parties without their consent especially things that look
like taking someone's coins and assigning them to someone else.

I think the root is that you believe that the miners are, should be,
or even could be trustworthy in ways that I do not,  and as a result
you expect to be able to extract the performance of a trusted
centralized system out of them that I do not. Bitcoin is a system
where the incentives are well enough aligned that you appear to only
need a small amount of altruism to make it reliable. ... and even
summoning that altruism is a challenge— as miners hand over control of
their hash-power to centralized pools (some known to have behaved
poorly in the past), etc.

I would like that performance if it came at no cost: But proposals
that miners conspiring to blacklist transactions/blocks produced by
other people is something with a risk of a worse violation of the
system's promises than some disagreement of the ordering of
unconfirmed transactions.  Pretty much immediately after your post
Peter Todd— in his trouble making manner— went and posted on reddit
proposing the mechanism be used to claw back mining income from a
hardware vendor accused of violating its agreements on the amount of
self mining / mining on customers hardware.  While Peter's suggestion
was no doubt intentionally trouble making— I'm not clear on where the
line is here: Harm from reordering pretty much non-existent currently
and is highly speculative, while the harm to miners by hardware
vendors who've promised to not compete with their own customers or use
their equipment is not at all speculative and very salient to miners.

This especially in light of the fact that the system already has an
equitable method to decide what order transactions should be in... but
instead you propose an additional complex heuristic system where based
on some unspecified collusion some majority of miners take a
minorities coins and assign them to themselves.

Unlike reorginization this form of wealth transferal has no collateral
damage meaning that a majority cabal can use it to deprive a minority
outsider of some or all income without risking disrupting the network,
it would also lay the groundwork for additional forms of censorship
which I believe would be at odds with the purpose and architecture of
the system... and, as I noted above, it wouldn't actually prevent
theft, it would just mean that no single block could make its theft
services available to all comers (or even any of the public at all).
The simple mechenism of allowing only only a small number of paid
reordering transactions per block would prevent forming a quorum on
the decision to revoke the coinbase, and you'd even get additional
income from the probe transactions without even helping any real
double spends at all. The incentives seem very hard to analyze.

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


 Yes, you can reorg out the blocks and actually remove them, but I

understood that you were _not_ proposing that quite specifically. But
 instead proposed without reorging taking txouts that were previously
 assigned to one party and simply assigning them to others.


Well, my original thought was just to delete the coinbases. But then some
people don't like the idea of destroying money (equivalently, reducing the
system's resolution) so I proposed reallocating it instead. I'm not sure
which is better though. Deletion is closer to what the existing system
allows, for sure.

Would you feel differently if the consequence was UTXO deletion rather than
reallocation? I think the difference makes no impact to the goal of
discouraging double spending.


 ... proposing the mechanism be used to claw back mining income from a
 hardware vendor accused of violating its agreements on the amount of
 self mining / mining on customers hardware.


I think this would not be doable in practice, unless there was a way to
identify that a block was mined with pre-sold equipment. Peter points out
that the pool in question is marking their blocks by reusing addresses -
ditto for the double spending against dice sites - but that's a trivial
thing for them to fix. Then it'd be difficult (impossible?) for miners to
identify KnC blocks even if there was a strong majority consensus to delete
their coinbases.

The reason I think this particular change is doable is that it should be
possible to quite reliably identify blocks that are Finney attacking for
profit. That doesn't generalise to any policy though. Blocks are intended
to be structurally identical to each other if best practices are followed
and even with the dire pool situation a big chunk of mining hash power
today is effectively anonymous.
--
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

On 4/23/14, Mike Hearn m...@plan99.net wrote:
 I guess word honest might have different meanings, that can be a source
 of confusing.
 1. Honest -- not trying to destroy bitcoin
 2. Honest -- following rules which are not required by the protocol


 I'm using it in the same sense Satoshi used it. Honest miners work to
 prevent double spends. That's the entire justification for their existence.

I thought the mechanism they used to prevent double-spends was proof of work.
Therefore dishonest miners where only those who mine on top of a block
which is not the longest valid chain they've seen.
To distinguish this definition from your own honest miners are those
who decide on double-spends by mining the transaction they saw first
definition I propose to give another new name to the later, instead of
changing the definition of the former.
So inside the group of honest miners we have some that decide on
transactions based on reception times and others that simply maximize
their revenue while respecting the protocol rules.
I suggest stupid miners and smart miners respectively as more
clear terms for what we're talking about here.

 Miners that are deliberately trying to double spend are worse than useless.

I completely disagree.
Miner's proof of work makes transactions irreversible. Even if zero
confirmation transactions weren't possible in a replace-by-fee
environment, that's very useful.
Even if you always had to wait for transactions to be confirmed with
some irreversible proof of work (as described in Satoshi's
whitepaper), it doesn't follow that automatically resolves the
Bitcoin experiment as a failure. I don't understand how can you
conclude that.

But in fact 0 conf txs are possible *precisely* using replace-by-fee,
as described in the 
0 confirmation txs using replace-by-fee and game theory thread. So
that conclusion is definitely wrong.

On your concrete proposal, it seems to me that you're trying to
prevent double-spending without relying on proof of work, which I
think it impossible in the context of a truly p2p system.
I don't think your current proposal is secure and I fear that at best
you will end up with an invite only transaction processing network
like Ripple.com has with their consensus algorithm and Unique Node
Lists: that's not really p2p.

-- 
Jorge Timón

http://freico.in/

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

On Thu, Apr 24, 2014 at 1:22 PM, Jorge Timón jti...@monetize.io wrote:

  I'm using it in the same sense Satoshi used it. Honest miners work to
  prevent double spends. That's the entire justification for their
 existence.

 I thought the mechanism they used to prevent double-spends was proof of
 work.
 Therefore dishonest miners where only those who mine on top of a block
 which is not the longest valid chain they've seen.


No! This is a misunderstanding. The mechanism they use to prevent double
spends is to *ignore double spends*. The blocks they created indicate the
ordering of transactions they saw and proof of work is used to arrive at a
shared consensus ordering given the possibility that transactions arrived
at different times.

I'm continually amazed at how many people seem to see the current algorithm
as the goal in and of itself, instead of an imperfect but workable means of
achieving the actual goal.

To distinguish this definition from your own honest miners are those
 who decide on double-spends by mining the transaction they saw first


This definition of honesty is not my own, the one Bitcoin has always used.
Obviously if Satoshi had wanted transactions to be double spendable by fee
in the mempool he would have made Bitcoin work that way, instead of coming
up with the nSequence based replacement scheme instead.

First-seen *is* a protocol rule, as much as Set-Cookie storing data in a
browser is an HTTP protocol rule. The fact that auditing compliance with it
is harder to do than some others does not make it less of a rule.

I completely disagree.
 Miner's proof of work makes transactions irreversible.


Again you are hopelessly confused. Miners that are trying to double spend
are *by definition* not making transactions irreversible, they are trying
to make transactions reversible.

Look at it this way. There is no inherent reason BitUndo has to undo only
Finney attacks. If it gets sufficient hash power it could offer undoing of
1-confirm transactions too, right? Sure it'll mostly fail but that's
already a part of its business model. Sometimes it'll get two blocks in a
row and succeed. It's a very minor tweak to what they're doing. Would you
argue these miners are still useful? After all, it's impossible to be
certain after the fact that miners built on top of the wrong block
because forks occur naturally.


 Even if you always had to wait for transactions to be confirmed with
 some irreversible proof of work (as described in Satoshi's
 whitepaper), it doesn't follow that automatically resolves the
 Bitcoin experiment as a failure. I don't understand how can you
 conclude that.


What I said is, if you believe all miners are willing to double spend for a
fee then this resolves the experiment as a failure. This is also obvious -
if you can pay miners to go back and rewrite the chain at will, Bitcoin
doesn't work.

Consider the incentives. Let's say all miners are smart in your
estimation and are willing to double spend transactions for higher fees.
Because all miners follow this ridiculous policy, they should be willing to
fork the chain at any point to claim the higher fee on the new tx. After
all, although they will throw away the work they did on the previous chain,
if the fee on the new tx is high enough to balance this then it can be
profitable for them to do it.

Because a double spender can afford to give nearly all of his new tx away
in fees, this means even txns well buried in the chain can be profitably
double spent: even if the double spender gets back only 10% of the
transferred amount, if it was a big transfer for some expensive object,
they still win! They got object + 10%

Do you see now why your definition of honesty is completely broken?
--
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

[Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

Here is a solution to the problem of having 0 confirmation
transactions that relies on game
theory and most miners implementing replace-by-fee and child-pays-for-parent.

This has been proposed before
http://sourceforge.net/p/bitcoin/mailman/message/30876033/
I'm just going to describe the general idea in more detail.

Here's a small draft on how this could work:

Alice goes to Bob's store and wants to buy something cheaper than a
car, say a smartphone.
So Bob says, it's 200 usd in btc, please pay me 400 usd in btc
So Alice signs a tx with 400 and no fee with her old phone and she
just sends it to Bob rather than the network.
Bob creates a child transaction keeping 200 and giving 199.9 (0.1 usd
fee) back to Alice.

But you know, Alice wants to double spend.
She double spends 399.8 to herself (0.2 fee)
Bob thinks last chance, he double-spends the child: 200 to Bob, back
199 to Alice (1 usd fee).
Alice is stubborn: 398 to Alice (2 usd fee).
Bob is really pissed off, double spends the child: 400 in fees.

So, ok, Bob lost the phone and got nothing but Alice has paid twice as
she needed for the phone.
Nobody's happy thus everybody's happy.

This is similar to the general game theory stag hunt case.
The payoff matrix could be something like this:

Bob returns change   Bob burns in fees
 -++---
  Alice behaves + 1 , + 1- 1, + 1
 -++---
  Alice double-spends   + 3, - 1 - 1, - 1

The game has two Nash equilibria, but cooperation is Pareto efficient.

Replace-by-fee and child-pays-for parent cannot be prohibited by a
protocol rule.
I believe all miners will eventually implement these policies because
it is the more rational way for them to prioritize transactions.
Finally I hope they do because it would make 0-confirmation
transactions possible as described in this post.
So I can't find any reasoning against replace-by-fee unless my example
is terribly flawed.
Am I missing something?

-- 
Jorge Timón

http://freico.in/

--
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] 0 confirmation txs using replace-by-fee and game theory


 Am I missing something?


The scheme you described does nothing about Finney attacks, which is the
issue presently faced.
--
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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Chris Pacia

This scheme would discourage people from attempting a Finney attack because
they would end up worse off if they did.

It would work but it's an ugly hack IMO. What do people do if they don't
have extra to pay when making a purchase? I have 200 mbtc and want to buy a
200 mbtc phone but I can't because I need 400 mbtc. Sucks for me.

I would much prefer the hassle of a green address notary than always having
to make sure I have double what I need to make a purchase.
On Apr 24, 2014 7:55 AM, Mike Hearn m...@plan99.net wrote:

 Am I missing something?


 The scheme you described does nothing about Finney attacks, which is the
 issue presently faced.


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


--
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] 0 confirmation txs using replace-by-fee and game theory


 This scheme would discourage people from attempting a Finney attack
 because they would end up worse off if they did.

Phrased another way, it simply makes every block a Finney attack that
charges the maximum double spending fee possible. This doesn't solve the
problem.

Beyond needing to double balances, what if the shop is selling me a phone
on contract? So the actual cost of the phone is lower than the real price
on the assumption of future revenue. Alice double spends (aka steals) the
phone, paying double the artifically lower cost but still making a good
saving. Bob does not end up with nothing, he ends up in the red.

But there's a much simpler way to dispose with this idea. Jorge, go down to
your local bars and cafes, and ask them if they'd be willing to accept a
form of payment that allows anyone to steal from them by simply paying
double the purchase price to some other random guy. They *will* look at you
as if you're crazy. Why would they ever do that?
--
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] Development Roadmap of Bitcoin Core 0.9.2

On Thu, Apr 24, 2014 at 10:25 AM, Wladimir laa...@gmail.com wrote:
 On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. wtog...@gmail.com wrote:

 But indeed we need to decide on a cut-off point. I'd have preferred
 4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010.
 Apart from tails it doesn't seem like anyone is using those old stable
 distributions on the desktop.

Does anyone know of the timeframe in which tails will switch to a
newer version of Qt?

As it's debian based: will switch to a Wheezy/7.4. Wheezy has Qt 4.8
so is decidedly unproblematic.

I see they're working on migration at least:

- https://tails.boum.org/blueprint/Wheezy/
- https://git-tails.immerda.ch/tails/log/?h=feature/wheezy

Wladimir

--
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] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Peter Todd

On Thu, Apr 24, 2014 at 12:48:54PM +0200, Jorge Timón wrote:
 Here is a solution to the problem of having 0 confirmation
 transactions

FWIW I'm running an experiment right now to detect how easy it is to
doublespend 0-conf transactions I need to collect more data, but initial
results indicate that transaction propagation is sufficiently unreliable
that double-spending frequently works without miners using
replace-by-fee even when both transactions pay high fees, there is a 60
second delay between first and second, and there's only about four
replace-by-fee nodes on the network.

With replace-by-fee scorched-earth the success rate of such
double-spends would be significantly reduced as the attacker would need
to get lucky with bad propagation not just once, but twice in a row.

 that relies on game
 theory and most miners implementing replace-by-fee and child-pays-for-parent.
 
 This has been proposed before
 http://sourceforge.net/p/bitcoin/mailman/message/30876033/
 I'm just going to describe the general idea in more detail.

Just to be clear, while that post is mine, original credit for the idea
actually goes to John Dillon as far as I know; I first heard about it
from him in private discussion.

 Replace-by-fee and child-pays-for parent cannot be prohibited by a
 protocol rule.
 I believe all miners will eventually implement these policies because
 it is the more rational way for them to prioritize transactions.
 Finally I hope they do because it would make 0-confirmation
 transactions possible as described in this post.
 So I can't find any reasoning against replace-by-fee unless my example
 is terribly flawed.
 Am I missing something?

A few things:

1) Replace-by-fee doesn't protect against sybil attacks; only
confirmations are solid evidence that a transaction has actually reached
the mining power and your communication channel to that mining power
isn't being blocked. Keep in mind that Bitcoin depends on the existence
of a jam-free network, and very importantly, lets you detect when that
network has failed and you are being jammed. No unconfirmed transaction
scheme can solve this problem in a decentralized network.

2) Replace-by-fee scorched earth does require you to keep private keys
online to sign the replacements. Not a big deal, but it's yet another
reason why you wouldn't want to use it for high-value stuff.

3) It doesn't directly solve finney attacks(1) where the miner mines the
transaction in private. However finney attacks are only relevant if
there is high centralization of hashing power, and all other proposed
mechanisms, e.g. coinbase reallocation, themselves do a lot of harm to
decentralization. (just look at how coinbase reallocation lets large
pools bully smaller miners out of business by blacklisting their blocks)

One interesting thing with regard to finney attacks and replace-by-fee
though is that enforcing hasher visibility of the blocks they are mining
- what getblocktemplate was meant to do voluntarily - lets any hasher
detect a finney attack double-spend and broadcast it. They have a weak
incentive to do so - the scorched earth reply is a high-fee transaction
of course and pre-broadcasting transactions makes blocks propagate
faster - at which point you're back to a public double-spend.  Enforcing
visibility of block contents to hashers is definitely a good thing for
decentralization.

1) https://bitcointalk.org/index.php?topic=3441.msg48384#msg48384

-- 
'peter'[:-1]@petertodd.org
93d8af23978adc9e201a1f2e2dc52844f9013a1da3621572


signature.asc
Description: Digital signature
--
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-24 Thread Peter Todd

On Thu, Apr 24, 2014 at 11:56:23AM +0200, Mike Hearn wrote:
  ... proposing the mechanism be used to claw back mining income from a
  hardware vendor accused of violating its agreements on the amount of
  self mining / mining on customers hardware.
 
 
 I think this would not be doable in practice, unless there was a way to
 identify that a block was mined with pre-sold equipment. Peter points out
 that the pool in question is marking their blocks by reusing addresses -
 ditto for the double spending against dice sites - but that's a trivial
 thing for them to fix. Then it'd be difficult (impossible?) for miners to
 identify KnC blocks even if there was a strong majority consensus to delete
 their coinbases.

Like I said before, that leads to the obvious next step of
deleting/stealing their coinbases if they don't identify themselves.

Another likely outcome would be for coinbase blacklisting to be used as
a way to force a minority of miners to adopt a transaction blacklist
that the majority of miners had adopted. Any block containing
transactions spending coins on the txout blacklist would itself be
punished by having the block reward either blacklisted or taken.

 The reason I think this particular change is doable is that it should be
 possible to quite reliably identify blocks that are Finney attacking for
 profit. That doesn't generalise to any policy though.

It's not possible to produce a cryptographic proof that a given block
engaged in a Finney attack. You're proposed coinbase blacklisting/reallocation
mechanism is simply a way of voting on what coinbases to either
blacklist or reallocation, nothing more.

-- 
'peter'[:-1]@petertodd.org
3d5f2a2a68690093cd99f8af1bc8395061251017019cc30a


signature.asc
Description: Digital signature
--
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

On 4/24/14, Mike Hearn m...@plan99.net wrote:
 No! This is a misunderstanding. The mechanism they use to prevent double
 spends is to *ignore double spends*. The blocks they created indicate the
 ordering of transactions they saw and proof of work is used to arrive at a
 shared consensus ordering given the possibility that transactions arrived
 at different times.

 I'm continually amazed at how many people seem to see the current algorithm
 as the goal in and of itself, instead of an imperfect but workable means of
 achieving the actual goal.

I'm not saying proof of work is the goal, the goal is still p2p
transaction serialization.
And that's achieved through proof of work, not through miner's honesty.

 This definition of honesty is not my own, the one Bitcoin has always used.

Whatever, let's keep calling stupid miners honest miners, smart
miners dishonest-by-replace-by fee miners and miners that do replace
by fee and also hash on top of old blocks utterly dishonest miners.

 Obviously if Satoshi had wanted transactions to be double spendable by fee
 in the mempool he would have made Bitcoin work that way, instead of coming
 up with the nSequence based replacement scheme instead.

Maybe Satoshi hadn't thought in depth about replace-by-fee when he
wrote the code.
Why should we care?
If nSequence was a design mistake Satoshi did, should we maintain it
to somehow honor him?
Maybe the payment protocol shouldn't have been developed because he
had some weird ideas about paying to ips? Maybe we shouldn't write any
tests because he didn't do so?
This persistent argument from authority is annoying.

 First-seen *is* a protocol rule, as much as Set-Cookie storing data in a
 browser is an HTTP protocol rule. The fact that auditing compliance with it
 is harder to do than some others does not make it less of a rule.

It is not a protocol rule that validators can use to discriminate the
longest valid chain and therefore is not enforceable. Not even through
a softfork because miners can't know which transactions other miners
saw first.
So if it is a protocol rule, I think it shouldn't be.

 Again you are hopelessly confused. Miners that are trying to double spend
 are *by definition* not making transactions irreversible, they are trying
 to make transactions reversible.

Miners that mine on top of the longest valid chain are helping in
making transactions irreversible whether they implement a first-saw or
a replace-by-fee policy.

 Look at it this way. There is no inherent reason BitUndo has to undo only
 Finney attacks. If it gets sufficient hash power it could offer undoing of
 1-confirm transactions too, right? Sure it'll mostly fail but that's
 already a part of its business model. Sometimes it'll get two blocks in a
 row and succeed. It's a very minor tweak to what they're doing. Would you
 argue these miners are still useful? After all, it's impossible to be
 certain after the fact that miners built on top of the wrong block
 because forks occur naturally.

That's not what I'm saying. Miners that don't mine on top of the
longest chain are dishonest by my own definition as well.
You want to equate replace-by-fee dishonesty with
trying-to-rewrite-history dishonesty by saying that the transactions
that have been seen in the network are already history and that's
where we disagree. I think only what's in the chain is history and I
also think that's the whole point of proof of work.
And I also disagree that all the people who think this way are
hopelessly confused. We may be confused, but I think there's always
hope for removing confusions provided that there's will to learn,
which I think it is at least my case.

 What I said is, if you believe all miners are willing to double spend for a
 fee then this resolves the experiment as a failure. This is also obvious -
 if you can pay miners to go back and rewrite the chain at will, Bitcoin
 doesn't work.

This is in fact quite polemic and thus obviously not obvious.
Bitcoin works because rewriting the chain gets exponentially more
expensive as time passes.

 Because all miners follow this ridiculous policy, they should be willing to
 fork the chain at any point to claim the higher fee on the new tx. After
 ...

 Do you see now why your definition of honesty is completely broken?

I see now that I may have not properly expressed myself in the earlier
post since you clearly misunderstood what I meant by smart miners.
By that I mean miners implementing replace-by-fee and
child-pays-for-parent policies Not miners trying to rewrite history,
which I agree is about as smart as mining on top of orphan blocks.

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

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


 Like I said before, that leads to the obvious next step of
 deleting/stealing their coinbases if they don't identify themselves.


And as I said before, that's a huge leap. A majority of miners deciding
double spending needs tougher enforcement doesn't imply they also think all
miners should identify themselves. Those are unrelated things.

This kind of totally unsupported obvious next step argument can be
applied to any proposal in any walk of life. We developed SPV clients? The
obvious next step is that miners have to stop being anonymous. We developed
floating fees? The obvious next step is that miners have to stop being
anonymous. The prior arguments sound absurd exactly because they're not
obvious or even logical - same as this.
--
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] 0 confirmation txs using replace-by-fee and game theory

On 4/24/14, Peter Todd p...@petertodd.org wrote:
 ...
 With replace-by-fee scorched-earth the success rate of such
 double-spends would be significantly reduced as the attacker would need
 to get lucky with bad propagation not just once, but twice in a row.

Interesting.

 Replace-by-fee and child-pays-for parent cannot be prohibited by a
 protocol rule.
 I believe all miners will eventually implement these policies because
 it is the more rational way for them to prioritize transactions.
 Finally I hope they do because it would make 0-confirmation
 transactions possible as described in this post.
 So I can't find any reasoning against replace-by-fee unless my example
 is terribly flawed.
 Am I missing something?

 A few things:

 1) Replace-by-fee doesn't protect against sybil attacks; only

No worse than the current situation.

 2) Replace-by-fee scorched earth does require you to keep private keys
 online to sign the replacements. Not a big deal, but it's yet another
 reason why you wouldn't want to use it for high-value stuff.

High-value transactions should wait for several confirmations.

 3) It doesn't directly solve finney attacks(1) where the miner mines the
 transaction in private. However finney attacks are only relevant if
 there is high centralization of hashing power, and all other proposed
 mechanisms, e.g. coinbase reallocation, themselves do a lot of harm to
 decentralization. (just look at how coinbase reallocation lets large
 pools bully smaller miners out of business by blacklisting their blocks)

Again, no worse than the current situation. And regular double-spends
attacks are much simpler than finney attacks.

 One interesting thing with regard to finney attacks and replace-by-fee
 though is that enforcing hasher visibility of the blocks they are mining
 - what getblocktemplate was meant to do voluntarily - lets any hasher
 detect a finney attack double-spend and broadcast it. They have a weak
 incentive to do so - the scorched earth reply is a high-fee transaction
 of course and pre-broadcasting transactions makes blocks propagate
 faster - at which point you're back to a public double-spend.  Enforcing
 visibility of block contents to hashers is definitely a good thing for
 decentralization.

Where can I read more about enforcing hashing visibility of block contents?
Sounds somewhat similar to p2pool to me but I'm not sure I understand it.

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


 And that's achieved through proof of work, not through miner's honesty.


You can't disentangle the two. Proof of work just makes a block chain hard
to tamper with. What it contains is arbitrary. Honest miners build a block
chain that's intended to stop double spending. Dishonest miners don't.
They're both engaging in proof of work, to different ends.


 Whatever, let's keep calling stupid miners honest miners


No, let's not. Your definition of smart miner is one I'd called stupid
miner (or possibly short bitcoin miner). They are miners who would
reduce the value of their coins, by making their own system less useful.
That's not smart, that's simply short termism taken to an extreme, sort of
like a business owner who puts so much pressure on his employees they all
quit. He might have gained a bit more profit in the short term, but only at
the cost of destroying his business that would have given lower but
sustainable returns over the long term.


 This persistent argument from authority is annoying.


Peter always says this too, but it's again an incorrect position. This is
not an argument from authority.

Why are we here? We are here because we were brought together by shared
goals.

What are those goals? They were defined at the start of the project by the
creator of the project.

Why do we issue 21 million coins and not 42? Because 21 million is the goal
everyone signed up for.

Why did everyone sign up for 21 million coins? Because that's what Satoshi
picked.


If someone asked us to change from 21 to 42 million coins, we'd probably
say no and the justification would be that this is the number we started
with. That's not argument from authority, it's just recognition that the
parameters of a shared project has to be defined somehow, and for Bitcoin
it was defined at the start.

Now the argument Gregory makes is that changing the block chain algorithm
in this way would be a violation of the social contract. This is a generic
outcome to be legitimately worried about - we don't want to change what
Bitcoin is in ways that would dismay its users. That just leads to a fork.

I argue that this isn't such a change because it makes nothing possible
that was previously impossible, it just makes it less disruptive, and the
*actual* shared goal of Bitcoin is not preserve the block chain algorithm
exactly as found in v0.1 but rather stop double spending.

You are arguing elsewhere that Bitcoin should allow double spending for a
fee. That *would* be a clear violation of the social contract!


 That's not what I'm saying. Miners that don't mine on top of the
 longest chain are dishonest by my own definition as well.


Right, but I don't accept this definition of honesty. That's not a
definition any man on the street would use:

If you pay for something with forged bank notes and walk out
immediately, you are honest. But if you pay for something with forged bank
notes and hang around for longer than 10 minutes, you are dishonest

That would sound silly to anyone because what's so special about 10
minutes? It's the act of passing counterfeit money and stealing from the
merchant that's the dishonest act, how long it takes is irrelevant.

In Bitcoin, the dishonest act by the user is signing for the same output
twice (ignoring special protocols here), and the dishonest act by the miner
is deviating from normal behaviour for a fee to try and trick the recipient
into believing they have been paid. The exact details are something
computer scientists care about, but the average Bitcoin user would not.


 And I also disagree that all the people who think this way are
 hopelessly confused. We may be confused, but I think there's always
 hope for removing confusions provided that there's will to learn,
 which I think it is at least my case.


Indeed and that's why we have these threads! These are fundamental issues
that simply must be debated.
--
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-24 Thread Peter Todd

On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote:
 Actually Peter, coinbase confiscations are a much worse mechanism for
 enforcement of widespread censorship rules than simple orphaning. They
 lose their power when the transaction miners are punished for can
 build up over time without losing their usefulness:
snip
 Of course, in such a dystopian future, orphaning would be the
 enforcement mechanism. It would be stupid to rely on coinbase
 reallocation/burning to do this task when the existing tools work so
 much better.

I don't disagree with you at an end stage, but the thing with coinbase
blacklists/confiscation is because it's a voting mechanism the initial
stages of enforcing widespread censorship rules with it are much easier.
For instance, if a 10% pool that has been forced/wants to blacklist
certain transactions can do so, and then vote to blacklist blocks that
do not abide by that blacklist. Casting that vote does them no harm.
Every time another pool joins the blacklist, there's no harm to them to
doing so.  At some point they will reach a majority, which causes the
blacklist to actually apply. The whole process happens smoothly, letting
the blacklist be applied safely and easily.  With orphaning/reorging on
the other hand you just can't be sure that the other miners will
actually adopt it, making adoption risky.

Of course, that's above and beyond the fact that you can't prove a
Finney attack happened to a third-party, making it easy to attack
smaller miners with Sybil attacks, get them creating blocks with
double-spends in them, and using that as an excuse to punish them.

 What's interesting is that this mechanism is especially tailored to
 blocking time sensitive transactions (that need to be confirmed
 now/soon, or are worthless), such that their total out-of-band fees
 can't build up over time. Double spending is one such category. I'm at
 a loss to come up with something else, but maybe someone has a good
 example?

Decentralized markets are a great example: the bids and orders they
depend on are time-senstive and become much less valuable if they get
delayed greatly.

-- 
'peter'[:-1]@petertodd.org
091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b


signature.asc
Description: Digital signature
--
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-24 Thread Sergio Lerner

On 23/04/2014 05:51 p.m., Mike Hearn wrote:
On Wed, Apr 23, 2014 at 10:44 PM, Adam Ritter arit...@gmail.com
mailto:arit...@gmail.com wrote:

Isn't a faster blockchain for transactions (maybe as a sidechain)
solving the problem? If there would be a safe way for
0-confirmation transactions, the Bitcoin blockchain wouldn't even
be needed.

The 10 minute average comes from a desire to balance wasted work due
to natural chain splits with latency. With a very fast block interval
you end up with lots of forks and things take longer to converge,
also, it can make attacks easier because an attacker is building on
his own blocks so he doesn't suffer propagation delays and the
attendant splits.

It's not clear you can just make a faster block chain. 10 minutes is
somewhat arbitrary, it could be 5 minutes and the system would still
work, but it probably can't be 5 seconds.
5 seconds block interval is possible. I've simulate it with great
success and I encourage anyone to repeat or check my simulations.

There are a very few protocol modifications that are required to allow 5
seconds block, and most of them have already been discussed in the forums.
For more information you can check my post:
http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
Also NimbleCoin is a new alt-coin that uses 5-sec block intervals,
allows 100 tps and it's based on BitcoinJ (NimbleCoinJ now). So not
only it is possible, but it was coded by Mike itself.
Important note: the 5-sec block interval method probably requires a
block reward forever. It doesn't work well if there is no block reward
at all.

Unfortunately for best physical-world usability you really need very
fast payments. A few seconds is competitive with modern credit cards.
Another solution to achieve 5 secs block intervals is this:
http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/

So the problem with 0-confirmations is solely of Bitcoin and other
alt-coins, new alt-coins may achieve instant transactions and no not
have to rely on 0-confirmations.

Best regards,
Sergio.

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

Thanks Sergio!

On Thu, Apr 24, 2014 at 5:13 PM, Sergio Lerner sergioler...@certimix.comwrote:

For more information you can check my post:
http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval/
Also NimbleCoin is a new alt-coin that uses 5-sec block intervals, allows
100 tps and it's based on BitcoinJ (NimbleCoinJ now). So not only it
is possible, but it was coded by Mike itself.

Fascinating! I think that's the first time I heard of an alt coin entirely
based on bitcoinj as its core implementation. Looking forward to your
release.

My understanding is that dogecoin suffers somewhat from having so many
headers. SPV clients have to download them all in sequence so the more
blocks you have, the more data they must download and thus the slower they
sync. Sync times for SPV wallets today are fast enough that unless you
spend six months in the jungle with your phone switched off, you probably
won't notice. With 5 second block times unless there's some other solution
you'd have much worse UX.

BTW, Pieter experimented with relaying blocks as hash lists (actually
merkleblocks) and I believe he found that it could often fail and be slower
if the mempools were not quite synced. At any rate, it was apparently more
complicated than it looked. That may be a side effect of trying to reuse
the Bloom filtering code however.

Another solution to achieve 5 secs block intervals is this:
http://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/

MinCen looks like a rather interesting idea. I will read the paper.
--
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

On 4/24/14, Mike Hearn m...@plan99.net wrote:
 You can't disentangle the two. Proof of work just makes a block chain hard
 to tamper with. What it contains is arbitrary. Honest miners build a block
 chain that's intended to stop double spending. Dishonest miners don't.
 They're both engaging in proof of work, to different ends.

Yes, you can disentangle replace-by-fee policies from rewriting
history attacks.
That's exactly what I'm saying.
Proof of work is the most important thing that makes the blockchain
hard to tamper with.

 Whatever, let's keep calling stupid miners honest miners


 No, let's not. Your definition of smart miner is one I'd called stupid
 miner (or possibly short bitcoin miner). They are miners who would
 reduce the value of their coins, by making their own system less useful.
 That's not smart, that's simply short termism taken to an extreme, sort of
 like a business owner who puts so much pressure on his employees they all
 quit. He might have gained a bit more profit in the short term, but only at
 the cost of destroying his business that would have given lower but
 sustainable returns over the long term.

Whatever, pick the terms yourself but let's just stick to the same ones, please.
I've read this argument before, but I simply don't buy it because I
disagree with the premise that replace-by-fee reduces the value of the
coins (not to mention we shouldn't assume miners stock coins for
long).
I think replace-by-fee policies are actually an improvement over
first-saw-first-included policies.

 This persistent argument from authority is annoying.


 Peter always says this too, but it's again an incorrect position. This is
 not an argument from authority.

I don't know about other occasions with other people but what you just
used with me was an argument from authority fallacy. Now you're using
a false analogy to try to convince us you didn't.

If I was saying we should change the maximum from 21 M to 100 M
because mining subsidies could continue for longer.
Mining subsidies aren't necessarily a good thing or
That's no justification for a hardfork or
That could destroy people's confidence in the currency
would be logical arguments.

No, because Satoshi picked 21 M would be an argument from authority fallacy.

 That's not what I'm saying. Miners that don't mine on top of the
 longest chain are dishonest by my own definition as well.


 Right, but I don't accept this definition of honesty. That's not a
 definition any man on the street would use:

Whatever let's use whatever definitions you want, if I don't like your
definition of honesty I will just invent a new term to define my own.

 If you pay for something with forged bank notes and walk out
 immediately, you are honest. But if you pay for something with forged bank
 notes and hang around for longer than 10 minutes, you are dishonest

Sorry, I don't see the analogy.

 That would sound silly to anyone because what's so special about 10
 minutes? It's the act of passing counterfeit money and stealing from the
 merchant that's the dishonest act, how long it takes is irrelevant.

10 minutes is what Satoshi picked. Just kidding...

 In Bitcoin, the dishonest act by the user is signing for the same output
 twice (ignoring special protocols here), and the dishonest act by the miner
 is deviating from normal behaviour for a fee to try and trick the recipient
 into believing they have been paid. The exact details are something
 computer scientists care about, but the average Bitcoin user would not.

People need to understand that Bitcoin transactions are not instant.
For instants transactions you need to rely somehow on trust, use some
trust-less offchain mechanism or use a payment protocol that would
make double-spending irrational (like the one described in the other
thread that uses replace-by-fee).
So I think miner's default behavior should be replace-by-fee. But that
doesn't imply that I want miners to rewrite pow-validated history.

--
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] 0 confirmation txs using replace-by-fee and game theory


 Of course if we're not comparing this with Bitcoin today and we're
 comparing it to some theoretical mechanism for instant p2p
 serialization without requiring proof of work then, yes, this concept
 is not very interesting.


Bitcoin's competition is not some theoretical perfect p2p system but
rather, bank notes and credit cards.
--
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-24 Thread Christophe Biocca

 Casting that vote does them no harm.
 Every time another pool joins the blacklist, there's no harm to them to doing 
 so.

I actually agree that this is a problem, but that's actually not
inherent in the proposed enforcement mechanism (just the current
voting rules).

Here's an alternate:

- To start a vote, you set aside a part of your coinbase with amount X
= their entire coinbase amount.
- Then you need 51 blocks with a yes vote before the coinbase
maturity of the target for the vote to be considered a success.
- Success means target coinbase has X coins reallocated/burned.
- Failure means vote-initiating coinbase has X coins reallocated/burned.

The incentives for voting miners are to vote yes if and only if they
dislike the targeted miner more than the initiator (all other monetary
effects are identical). That isn't a bulletproof way to force miners
to only punish double spenders (rather than anything they dislike in
general), but it removes the risk free nature of trying to take away
another miner's coinbase.

It means that you'll need a high level of confidence other miners are
on your side before taking a risk, but, because you've got a much
longer time frame than 10 minutes, you can get manual confirmation
from other miners.

On Thu, Apr 24, 2014 at 11:03 AM, Peter Todd p...@petertodd.org wrote:
 On Thu, Apr 24, 2014 at 10:47:35AM -0400, Christophe Biocca wrote:
 Actually Peter, coinbase confiscations are a much worse mechanism for
 enforcement of widespread censorship rules than simple orphaning. They
 lose their power when the transaction miners are punished for can
 build up over time without losing their usefulness:
 snip
 Of course, in such a dystopian future, orphaning would be the
 enforcement mechanism. It would be stupid to rely on coinbase
 reallocation/burning to do this task when the existing tools work so
 much better.

 I don't disagree with you at an end stage, but the thing with coinbase
 blacklists/confiscation is because it's a voting mechanism the initial
 stages of enforcing widespread censorship rules with it are much easier.
 For instance, if a 10% pool that has been forced/wants to blacklist
 certain transactions can do so, and then vote to blacklist blocks that
 do not abide by that blacklist. Casting that vote does them no harm.
 Every time another pool joins the blacklist, there's no harm to them to
 doing so.  At some point they will reach a majority, which causes the
 blacklist to actually apply. The whole process happens smoothly, letting
 the blacklist be applied safely and easily.  With orphaning/reorging on
 the other hand you just can't be sure that the other miners will
 actually adopt it, making adoption risky.

 Of course, that's above and beyond the fact that you can't prove a
 Finney attack happened to a third-party, making it easy to attack
 smaller miners with Sybil attacks, get them creating blocks with
 double-spends in them, and using that as an excuse to punish them.

 What's interesting is that this mechanism is especially tailored to
 blocking time sensitive transactions (that need to be confirmed
 now/soon, or are worthless), such that their total out-of-band fees
 can't build up over time. Double spending is one such category. I'm at
 a loss to come up with something else, but maybe someone has a good
 example?

 Decentralized markets are a great example: the bids and orders they
 depend on are time-senstive and become much less valuable if they get
 delayed greatly.

 --
 'peter'[:-1]@petertodd.org
 091ae589c034bc0466e2feca51dc018bb2c3303e8ab8648b

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