[Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Mike Hearn
Lately someone launched Finney attacks as a service (BitUndo). As a
reminder for newcomers, Finney attacks are where a miner secretly works on
a block containing a double spend. When they eventually find a block, they
run to the merchant and pay, then broadcast the block. In a simpler variant
of this attack you make purchases as normal with a modified wallet that
always submits a double spend to the service, and then N% of the time where
N is the percentage of overall hash power the dishonest miners have, you
get your money back minus their fee.

N does not need to be very high to render Bitcoin much less useful. Real
time transactions are very important. Although I never expected it when I
first started using Bitcoin, nowadays most of my purchases with it are for
food and drink. If Bitcoin could not support such purchases, I would use it
much less.
Even with their woeful security many merchants see 1-2% credit card
chargeback rates, and chargebacks can be disputed. In fact merchants win
about 40% of chargeback disputes. So if N was only, say, 5%, and there was
a large enough population of users who were systematically trying to
defraud merchants, we'd already be having worse security than magstripe
credit cards. EMV transactions have loss rates in the noise, so for
merchants who take those Bitcoin would be dramatically less secure.

The idea of discouraging blocks that perform Finney attacks by having
honest miners refuse to build on them has been proposed. But it has a
couple of problems:

   1. It's hard to automatically detect Finney attacks. Looking for blocks
   that contain unseen transactions that override the mempool doesn't work -
   the dishonest users could broadcast all their double spends once a Finney
   block was found and then broadcast the block immediately afterwards, thus
   making the block look like any other would in the presence of double spends.

   2. If they could be automatically identified, it possibly could be
   converted into a DoS on the network by broadcasting double spends in such a
   way that the system races, and every miner produces a block that looks like
   a Finney attack to some of the others. The chain would stop advancing.

   3. Miners who want to vote no on a block take a big risk, they could
   be on the losing side of the fork and end up wasting their work.

We can resolve these problems with a couple of tweaks:

   1. Dishonest blocks can be identified out of band, by having honest
   miners submit double spends against themselves to the service anonymously
   using a separate tool. When their own double spend appears they know the
   block is bad.

   2. Miners can vote to reallocate the coinbase value of bad blocks before
   they mature. If a majority of blocks leading up to maturity vote for
   reallocation, the value goes into a pot that subsequent blocks are allowed
   to claim for themselves. Thus there is no risk to voting no on a block,
   the work done by the Finney attacker is not wasted, and users do not have
   to suffer through huge reorgs.

This may seem a radical suggestion, but I think it's much less radical than
some of the others being thrown around.

The above approach works as long as the majority of hashpower is honest,
defined to mean, working to stop double spending. This is the same security
property as described in the white paper, thus this introduces no new
security assumptions. Note that assuming *all* miners are dishonest and are
willing to double spend automatically resolves the Bitcoin experiment as a
failure, because that would invalidate the entire theory upon which the
system is built. That doesn't mean the assumption is wrong! It may be that
an entirely unregulated market for double spending prevention cannot work
and the participants eventually all end up trashing the commons - but the
hope is that smart incentives can replace the traditional reliance on law
and regulation to avoid this.

The voting mechanism would only apply to coinbases, not arbitrary
transactions, thus it cannot be used to steal arbitrary users bitcoins. A
majority of miners can already reallocate coinbases by forking them out,
but this wastes energy and work presenting a significant discouragement to
vote unless you already know via some out of band mechanism that you have a
solid majority. Placing votes into the coinbase scriptSig as is done with
other things avoids that problem.

The identification of Finney blocks relies on miners to take explicit
action, like downloading and running a tool that submits votes via RPC. It
can be expected that double spending services would try to identify and
block the sentinel transactions, which is why it's better to have the code
that fights this arms race be out of process and developed externally to
Bitcoin Core itself, which should ultimately just enforce the new (forking)
rule change.
--
Start Your Social Network Today - Download eXo 

Re: [Bitcoin-development] bits: Unit of account

2014-04-23 Thread Danny Hamilton
It seems to me that xbit is no more distinct or intuitive than µbit. In
either case it's simply an arbitrary character in front of the word bit.
Of course, for the majority of the world familiar with SI, the µ actually
adds additional meaning that is lost with the x.

Furthermore, given the multiple concerns voiced about the overuse of the
word bit, µBTC seems to solve the problem.

Since we are talking about how it would be displayed in software, we don't
need to be concerned about how people will pronounce it, or what the
nickname will be.  If most of the wallets start displaying amounts in µBTC
quantities, it will be obvious that a µBTC is a different magnitude than a
BTC.  Nobody is going to look at their 100,000 µBTC balance and think they
have 100,000 BTC. People will immediately make the mental adjustment to the
new order of magnitude even if they don't specifically know that µ means
micro, or that micro means 1e-6.

Nicknames will form organically (much like buck, fin, large, k, grand, and
benny for U.S. currency), I've always been partial to milly (or millie) and
mike (or micky) as nicknames for mBTC and µBTC.  I've personally used those
when speaking with people, and they seem to catch on pretty quickly.

As has already been mentioned, you're going to be hard pressed to find
software that denotes U.S. balances in bucks.  There isn't any good
reason to be coding a nickname like bit, xbit, or mike into wallet
software.

-  Danny Hamilton


On Tue, Apr 22, 2014 at 8:51 AM, Aaron Axvig aa...@axvigs.com wrote:

 That piece of horse equipment is called a bit in the US too.  But the point
 stands: most people don't use bit on a daily basis other than referring
 to
 a little bit of something.

 -Original Message-
 From: Wladimir [mailto:laa...@gmail.com]
 Sent: Sunday, April 20, 2014 11:27 AM
 To: Chris Pacia
 Cc: Bitcoin Dev
 Subject: Re: [Bitcoin-development] bits: Unit of account

 On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia ctpa...@gmail.com wrote:
  The term bit is really only overloaded for those who are techy. 95% of
  the population never uses the term bit in their daily lives and I
  doubt most could even name one use of the term.
  Plus bit used to be a unit of money way back when, so this is kind of
  reclaiming it. I think it's a great fit.

 That's a very anglocentric way of thinking.

 Here in the Netherlands, a bit is something you put in a horses's mouth.
 It's also used as imported word (in the information sense).
 We've never used the term for money.

 Wladimir


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


 --
 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] bits: Unit of account

2014-04-23 Thread Tamas Blummer
The problem is µBTC that bit tries to solve. 

BTC, mBTC and µBTC are just too similiar for enyone else than engineers. The 
mixed use of them leads to misunderstanding. 
I think adoption would benefit of a single unit with easily remembered and 
associated name that has no smaller than 1/100 fractions called satoshis.

Regards,

Tamás Blummer
Founder, CEO

http://bitsofproof.com

On 23.04.2014, at 11:44, Danny Hamilton danny.hamil...@gmail.com wrote:

 It seems to me that xbit is no more distinct or intuitive than µbit. In 
 either case it's simply an arbitrary character in front of the word bit.  
 Of course, for the majority of the world familiar with SI, the µ actually 
 adds additional meaning that is lost with the x.
 
 Furthermore, given the multiple concerns voiced about the overuse of the word 
 bit, µBTC seems to solve the problem.
 
 Since we are talking about how it would be displayed in software, we don't 
 need to be concerned about how people will pronounce it, or what the nickname 
 will be.  If most of the wallets start displaying amounts in µBTC quantities, 
 it will be obvious that a µBTC is a different magnitude than a BTC.  Nobody 
 is going to look at their 100,000 µBTC balance and think they have 100,000 
 BTC. People will immediately make the mental adjustment to the new order of 
 magnitude even if they don't specifically know that µ means micro, or that 
 micro means 1e-6.
 
 Nicknames will form organically (much like buck, fin, large, k, grand, and 
 benny for U.S. currency), I've always been partial to milly (or millie) and 
 mike (or micky) as nicknames for mBTC and µBTC.  I've personally used those 
 when speaking with people, and they seem to catch on pretty quickly.
 
 As has already been mentioned, you're going to be hard pressed to find 
 software that denotes U.S. balances in bucks.  There isn't any good reason 
 to be coding a nickname like bit, xbit, or mike into wallet software.
 
 -  Danny Hamilton
 
 
 On Tue, Apr 22, 2014 at 8:51 AM, Aaron Axvig aa...@axvigs.com wrote:
 That piece of horse equipment is called a bit in the US too.  But the point
 stands: most people don't use bit on a daily basis other than referring to
 a little bit of something.
 
 -Original Message-
 From: Wladimir [mailto:laa...@gmail.com]
 Sent: Sunday, April 20, 2014 11:27 AM
 To: Chris Pacia
 Cc: Bitcoin Dev
 Subject: Re: [Bitcoin-development] bits: Unit of account
 
 On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia ctpa...@gmail.com wrote:
  The term bit is really only overloaded for those who are techy. 95% of
  the population never uses the term bit in their daily lives and I
  doubt most could even name one use of the term.
  Plus bit used to be a unit of money way back when, so this is kind of
  reclaiming it. I think it's a great fit.
 
 That's a very anglocentric way of thinking.
 
 Here in the Netherlands, a bit is something you put in a horses's mouth.
 It's also used as imported word (in the information sense).
 We've never used the term for money.
 
 Wladimir
 
 
 --
 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
 
 --
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java 

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

2014-04-23 Thread Andy Parkins
On Wednesday 23 Apr 2014 08:55:30 Mike Hearn wrote:

 Even with their woeful security many merchants see 1-2% credit card
 chargeback rates, and chargebacks can be disputed. In fact merchants win
 about 40% of chargeback disputes. So if N was only, say, 5%, and there
 was a large enough population of users who were systematically trying to
 defraud merchants, we'd already be having worse security than magstripe
 credit cards. EMV transactions have loss rates in the noise, so for
 merchants who take those Bitcoin would be dramatically less secure.

Just pedantry: 100% of credit card transactions _can_ be fradulantly charged 
back but arent.  In fact, only 2% are ever attempted.

If N was 5%, then only 5% of bitcoin transactions _could_ be fraudulantly 
charged back; so then why wouldn't only 2% of those bitcoin transactions 
be fraudulant too, just as in the CC case?

The comparison would then be 2% chargebacks for credit cards, equivalent to 
0.1% (5%*2%) for bitcoin.


Not that I think that makes anything else you say invalid.



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] bits: Unit of account

2014-04-23 Thread Chris D'Costa
I have a rather off-beat suggestion. Perhaps decimal was not satoshi's 
intention.

In old English money 1 guinea is 21 shillings. I wonder if 1 million guineas is 
more or less the total number of bitcoins = 21 million shillings. There was 
also the notion of bits (two bob bits = 1 florin = 2 shillings). I quite like 
the idea as it's absolutely not expected.

Old English money is a funny mix of decimal and imperial (base12) measures but 
may have some interesting properties, one of which would be to have multiple 
names for overlapping layers not just the 2 or 3 that has been mentioned here 
and elsewhere.

I wonder in the long run if this will not just naturally occur anyway.

Regards

Chris D'Costa

Email: chris_dco...@meek.io

Sent from my iPhone

 On 23 Apr 2014, at 11:56, Tamas Blummer ta...@bitsofproof.com wrote:
 
 The problem is µBTC that bit tries to solve. 
 
 BTC, mBTC and µBTC are just too similiar for enyone else than engineers. The 
 mixed use of them leads to misunderstanding. 
 I think adoption would benefit of a single unit with easily remembered and 
 associated name that has no smaller than 1/100 fractions called satoshis.
 
 Regards,
 
 Tamás Blummer
 Founder, CEO
 email.png
 http://bitsofproof.com
 
 On 23.04.2014, at 11:44, Danny Hamilton danny.hamil...@gmail.com wrote:
 
 It seems to me that xbit is no more distinct or intuitive than µbit. In 
 either case it's simply an arbitrary character in front of the word bit.  
 Of course, for the majority of the world familiar with SI, the µ actually 
 adds additional meaning that is lost with the x.
 
 Furthermore, given the multiple concerns voiced about the overuse of the 
 word bit, µBTC seems to solve the problem.
 
 Since we are talking about how it would be displayed in software, we don't 
 need to be concerned about how people will pronounce it, or what the 
 nickname will be.  If most of the wallets start displaying amounts in µBTC 
 quantities, it will be obvious that a µBTC is a different magnitude than a 
 BTC.  Nobody is going to look at their 100,000 µBTC balance and think they 
 have 100,000 BTC. People will immediately make the mental adjustment to the 
 new order of magnitude even if they don't specifically know that µ means 
 micro, or that micro means 1e-6.
 
 Nicknames will form organically (much like buck, fin, large, k, grand, and 
 benny for U.S. currency), I've always been partial to milly (or millie) and 
 mike (or micky) as nicknames for mBTC and µBTC.  I've personally used those 
 when speaking with people, and they seem to catch on pretty quickly.
 
 As has already been mentioned, you're going to be hard pressed to find 
 software that denotes U.S. balances in bucks.  There isn't any good reason 
 to be coding a nickname like bit, xbit, or mike into wallet software.
 
 -  Danny Hamilton
 
 
 On Tue, Apr 22, 2014 at 8:51 AM, Aaron Axvig aa...@axvigs.com wrote:
 That piece of horse equipment is called a bit in the US too.  But the point
 stands: most people don't use bit on a daily basis other than referring to
 a little bit of something.
 
 -Original Message-
 From: Wladimir [mailto:laa...@gmail.com]
 Sent: Sunday, April 20, 2014 11:27 AM
 To: Chris Pacia
 Cc: Bitcoin Dev
 Subject: Re: [Bitcoin-development] bits: Unit of account
 
 On Sun, Apr 20, 2014 at 6:19 PM, Chris Pacia ctpa...@gmail.com wrote:
  The term bit is really only overloaded for those who are techy. 95% of
  the population never uses the term bit in their daily lives and I
  doubt most could even name one use of the term.
  Plus bit used to be a unit of money way back when, so this is kind of
  reclaiming it. I think it's a great fit.
 
 That's a very anglocentric way of thinking.
 
 Here in the Netherlands, a bit is something you put in a horses's mouth.
 It's also used as imported word (in the information sense).
 We've never used the term for money.
 
 Wladimir
 
 
 --
 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
 
 --
 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
 

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

2014-04-23 Thread Christophe Biocca
Just a few issues with the idea as it currently stands:

1. This provides a very strong incentive to always vote for
reallocating a block if it isn't yours, regardless of whether it's bad
or not (there's a positive expected return to voting to reallocate
coinbases from other miners). The incentive is bigger the more hash
power you have. You can partially address this by:
a) Requiring supermajorities
b) Requiring a vote to include proof of a double spend (that's not
a very strong safeguard, since anyone can create them after the fact
if one of their own transactions has been included).
c) Burning, rather than reallocating, the coins. Miners' immediate
incentive to attack honest pools is much reduced.

2. BitUndo gets paid using additional txouts in the double-spend
transaction, no by miner's fees. This means that the coinbase
transaction will represent a smaller and smaller share of their
revenues over time (however if the total honest transaction fees they
get in their block are high enough, the risk of losing those might
still be enough).

On Wed, Apr 23, 2014 at 3:55 AM, Mike Hearn m...@plan99.net wrote:
 Lately someone launched Finney attacks as a service (BitUndo). As a reminder
 for newcomers, Finney attacks are where a miner secretly works on a block
 containing a double spend. When they eventually find a block, they run to
 the merchant and pay, then broadcast the block. In a simpler variant of this
 attack you make purchases as normal with a modified wallet that always
 submits a double spend to the service, and then N% of the time where N is
 the percentage of overall hash power the dishonest miners have, you get your
 money back minus their fee.

 N does not need to be very high to render Bitcoin much less useful. Real
 time transactions are very important. Although I never expected it when I
 first started using Bitcoin, nowadays most of my purchases with it are for
 food and drink. If Bitcoin could not support such purchases, I would use it
 much less.
 Even with their woeful security many merchants see 1-2% credit card
 chargeback rates, and chargebacks can be disputed. In fact merchants win
 about 40% of chargeback disputes. So if N was only, say, 5%, and there was a
 large enough population of users who were systematically trying to defraud
 merchants, we'd already be having worse security than magstripe credit
 cards. EMV transactions have loss rates in the noise, so for merchants who
 take those Bitcoin would be dramatically less secure.

 The idea of discouraging blocks that perform Finney attacks by having honest
 miners refuse to build on them has been proposed. But it has a couple of
 problems:

 It's hard to automatically detect Finney attacks. Looking for blocks that
 contain unseen transactions that override the mempool doesn't work - the
 dishonest users could broadcast all their double spends once a Finney block
 was found and then broadcast the block immediately afterwards, thus making
 the block look like any other would in the presence of double spends.

 If they could be automatically identified, it possibly could be converted
 into a DoS on the network by broadcasting double spends in such a way that
 the system races, and every miner produces a block that looks like a Finney
 attack to some of the others. The chain would stop advancing.

 Miners who want to vote no on a block take a big risk, they could be on
 the losing side of the fork and end up wasting their work.

 We can resolve these problems with a couple of tweaks:

 Dishonest blocks can be identified out of band, by having honest miners
 submit double spends against themselves to the service anonymously using a
 separate tool. When their own double spend appears they know the block is
 bad.

 Miners can vote to reallocate the coinbase value of bad blocks before they
 mature. If a majority of blocks leading up to maturity vote for
 reallocation, the value goes into a pot that subsequent blocks are allowed
 to claim for themselves. Thus there is no risk to voting no on a block,
 the work done by the Finney attacker is not wasted, and users do not have to
 suffer through huge reorgs.

 This may seem a radical suggestion, but I think it's much less radical than
 some of the others being thrown around.

 The above approach works as long as the majority of hashpower is honest,
 defined to mean, working to stop double spending. This is the same security
 property as described in the white paper, thus this introduces no new
 security assumptions. Note that assuming all miners are dishonest and are
 willing to double spend automatically resolves the Bitcoin experiment as a
 failure, because that would invalidate the entire theory upon which the
 system is built. That doesn't mean the assumption is wrong! It may be that
 an entirely unregulated market for double spending prevention cannot work
 and the participants eventually all end up trashing the commons - but the
 hope is that smart incentives can replace 

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

2014-04-23 Thread Andy Parkins
On Wednesday 23 Apr 2014 12:45:34 Mike Hearn wrote:

 OK, sure, let's say most Bitcoin users will be honest (we hope). But
 unfortunately in a situation where fraud is possible users wouldn't
 necessarily distribute evenly over transactions.

That's true, but even in the worst that that 5% hashing power attack means 
that 95% of the time, your attack fails.  That means you end up paying for 
what you bought.  Also, you're again changing the comparison basis -- your 
CC figures were for the entire industry, not the most badly affected 
merchant.  You can't say one particular bitcoin merchant suffers 5% fraud, 
therefore that's worse than the 2% fraud averaged across all CC merchants.

 If a merchant is selling something of value repeatedly, then a small
 number of scammers can go back and try their luck over and over. I'm not
 sure how many trades fall into such an exploitable category, though.

 Also, there's the philosophical question of how honest people really are
 when there's no consequences to their actions. For instance, if most

There _are_ consequences though: 95% of the time, you end up buying 
something and paying for it.

Viewed another way, if I buy something repeatedly from an at risk merchant 
(and there won't be many; as you pointed out, mail order is completely 
unaffected as you can simply wait for your confirmations) that costs, say 
0.01 BTC per item, then I have to buy 100 of them to get 5 of them for free.  
Do I really want 100 of them?  Even if I do want them, then I've had to 
supply capital of 1 BTC to earn 0.05 BTC in kind.

If what I'm buying is another form of money (as with exchanges, or perhaps 
casinos) when that in kind is just as liquid as the BTC, then fair enough, 
there is a risk, but that just incentivises the merchant in those cases to 
not allow withdrawal/deposit until 6 confirmations have been received.  
Those merchants then move from at risk to not at risk.

I'm still struggling to see how bitcoin could ever be as bad as CC fraud.



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-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/23/2014 07:55 AM, Mike Hearn wrote:

 2. Miners can vote to reallocate the coinbase value of bad blocks
 before they mature. If a majority of blocks leading up to maturity
 vote for reallocation, the value goes into a pot that subsequent
 blocks are allowed to claim for themselves. Thus there is no risk
 to voting no on a block, the work done by the Finney attacker is
 not wasted, and users do not have to suffer through huge reorgs.

If enough miners don't like a block that has been mined, they can all
work to orphan it without any change to the protocol whatsoever.

Why are proposing this a change to the network that allows miners to
vote to disregard output scripts, instead of creating an out of band
network via which miners can coordinate actions using the capabilities
the protocol already allows?

Once you've changed the network such that it is no longer a machine
that faithfully processes scripts, and instead is a machine via which
a set of controllers can decide which valid scripts will be honored
and which ones will not, what will be the next proposed condition
under which the miners can confiscate and redistribute balances?

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTV9OUAAoJECoisBQbQ4v0XE8H+QGcOc3JiYsS2/xoR8SqpyEx
gDChDFvhaao9qMPhfxBG0bso+4ITZ5c3mJawkqdBm3ZZPeygt1fLqvxe4c1AWocH
YCf9CyZJlm8KsDJOqorja5o/6oXjH5xiGgVi042Jhb9wj/aGNPFvL9X6DGhEeFKQ
uXFN4wTSPViEOryVqo3vEFh3md9Y1AIqcvc/b5M+EAtvaAD33/ALnzY9CNKymQZE
o0JGLEfwamKkZ+QA0mTfeDheJe9kj0KOQhXqOG/x3NlKCFVpmGz3daWZHJCFMDb4
+RmDwoxOKvXxgveXu9w4d3bc3SQZ75hygmeMvVQwZggia31wqrHtsWLqIiFhVnU=
=hpdg
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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 Alex Mizrahi
This is outright ridiculous.

Zero-confirmation double-spending is a small problem, and possible
solutions are known. (E.g. trusted third party + multi-sig addresses for
small-value transactions.)

On the other hand, protocol changes like described above might have
game-theoretical implications which are non-trivial and hard to understand.

The above approach works as long as the majority of hashpower is honest,
 defined to mean, working to stop double spending. This is the same security
 property as described in the white paper, thus this introduces no new
 security assumptions.


No. Bitcoin should work if miners are merely individually rational, i.e.
they try to maximize their pay-offs without colluding with others.

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
--
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] Economics of information propagation

2014-04-23 Thread Peter Todd
On Mon, Apr 21, 2014 at 01:30:28AM +, Jonathan Levin wrote:

CC'ing bitcoin-research - may be more appropriate to move the discussion
there as this discussion is delving into future scenarios.

 Hi all,
 
 I am a post-graduate economist writing a paper on the incentives of mining. 
 Even though this issue has been debated in the forums, I think it is 
 important to get a sense of the magnitude of the incentives at play and 
 determine what implications this has for the transaction fee market.
 
 As it has been pointed out before the marginal cost for miners does not stem 
 from the private cost of the miner validating the signature and including it 
 in the list of transactions in the block but rather the increased probability 
 that the block will be orphaned as a result of slower propagation. Gavin did 
 some back of the envelope worst case calculations but these overstated the 
 effect of propagation delay. The reason being the 80ms additional time to 
 reach 50% of the network is spread throughout the time that it takes to reach 
 50% of the network. During this time miners are notified about the block and 
 treat it as the longest chain and hence are no longer mining with the aim to 
 produce a competing block. 
 
 I am looking to calculate the change in the curvature of the probability mass 
 function that a block hears about my block in any given second as a function 
 of the block size. Although there is likely to be significant noise here, 
 there seems to be some stable linear relationships with the time that it 
 takes to reach different quartiles. Has anyone done this? I have used some 
 empirical data that I am happy to share but ideally I would like analytical 
 solutions.
 
 Following Peter Todd, I also find the concerning result that propagation 
 delays results in increasing returns to higher shares of the hashing power. 
 Indeed it may well be in the interest of large pools to publish large blocks 
 to increase propagation delays on the network which would increase orphan 
 rates particularly for small miners and miners that have not invested in 
 sufficient bandwidth / connectivity. If a small miner hears about a block 
 after 4.5 seconds on average there is a 0.7% chance that there is already a 
 block in circulation.  Large miners can increase the time that it takes for 
 small miners to hear about blocks by increasing the size of their blocks. For 
 example if the time that it takes for a small miner to hear about the block 
 goes to 12 seconds there is a 2 percent chance there is already a block in 
 circulation for the small miner. There is also a 1.2% chance that there will 
 be a competing block published after a small miner propagates in the time 
 that it gets to full propagation. Am I getting this right that the 
 probability of a miner’s block being orphaned is comprised of the probability 
 that the miner was not the first to find a valid block and the probability 
 that given they are first, someone else in the absence of hearing about it 
 finds a competing valid block. 
 
 One question is: Are orphans probabilistic and only resolved after hearing 
 about a new block that lengthens the chain or is there a way to know in 
 advance?

They're probabilistic; mining is progress free so per unit hashing power
every miner has an equal chance of finding a block. As for resolution,
well, currently nodes (and miners) mine on the block they saw first; if
they learn about another block at the same height they stick to the
block they are already mining on. First seen at same height is probably
generally economically rational as the first block you see probably
propagated to the most nodes, although tweaks to that are probably
possible.

 Is it frowned upon to mine on top of a block that you have just found even 
 though it is very likely going to end up an orphan?

Not at all, in fact mining on top of the block is the best thing to do
because it *prevents* your block from ending up as an orphan. Basically
imagine I find block b1a, and you find conflicting block b1b. What I
need to do is find block b2a, which is on top of b1a, before you find
block b1b to avoid my block being orphaned. The best way to do that is
mining on top of my block - that's what's most rational for me.

 Would be happy to share the draft form of the paper and receive any feedback.

Sure thing.

 Finally, at coinometrics we are working on a modified client to capture 
 information on network propagation and would invite any suggestions of any 
 other useful statistics that would be useful in the development of software. 


So looking at the replies your post got in the past few days it looks
like there's some misinformation going around. First of all is the
question of how harmful it is if miners mine on top of blocks that they
haven't actually validated, and yes, that's extremely harmful. For
instance if I were an attacker I could mine an invalid block that makes
coins out of thin air and use it to defraud 

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

2014-04-23 Thread Alex Mizrahi
 And it still would. Non-collusive miners cast votes based on the outcome
 of their own attempts to double spend.


Individually rational strategy is to vote for coinbase reallocation on
every block.

Yes, in that case nobody will get reward. It is similar to prisoner's
dilemma: equilibrium has worst pay-off.
In practice that would mean that simple game-theoretic models are no longer
applicable, as they lead to absurd results.


 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.
 Miners that are deliberately trying to double spend are worse than useless.


Miners work to get rewards.
It absolutely doesn't matter whether they are deliberately trying to
double-spend or not: they won't be able to double-spend without a collusion.
--
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 Pieter Wuille
On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote:
 I have some questions:
 1.  How can we work towards solving the double-spending problem?

We have this awesome technology that solves the double-spending
problem. It's called a blockchain. Of course, it only works when
transactions are actually in a block.

This issue is about double-spending preventing before they're
confirmed. This is (and has always been) just a best-effort mechanism
in the network.

 2.  Is it possible to scan for double-spending and correct it?

That is what is being proposed here, by introducing a mechanism where
miners can vote to penalize other miners if they seem to allow (too
many?) double spends.

 3.  Is the network at large not secure enough?

Not very relevant.

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


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

2014-04-23 Thread Peter Todd
On Wed, Apr 23, 2014 at 05:41:26PM +0200, Pieter Wuille wrote:
 On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote:
  I have some questions:
  1.  How can we work towards solving the double-spending problem?
 
 We have this awesome technology that solves the double-spending
 problem. It's called a blockchain. Of course, it only works when
 transactions are actually in a block.
 
 This issue is about double-spending preventing before they're
 confirmed. This is (and has always been) just a best-effort mechanism
 in the network.
 
  2.  Is it possible to scan for double-spending and correct it?
 
 That is what is being proposed here, by introducing a mechanism where
 miners can vote to penalize other miners if they seem to allow (too
 many?) double spends.

Worse, it's a mechanism where miners can vote to penalize other miners
for any reason at all. Nothing in the mechanism requires any proof that
a double-spend happened, nor can it.  Even if you require the simple
two signatures for same output mechanism, that just proves the
existance of a second signature, and says nothing at all about whether
or not that signature was ever broadcast on any network.

-- 
'peter'[:-1]@petertodd.org
278031f86c71265f6eaf1fe9ce6cc831dc4f956676a7a7f7


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-23 Thread Christophe Biocca
It's not necessary that this coinbase retribution be either
profitable or risk-free for this scheme to work. I think we should
separate out the different layers of the proposal:

1. Attacking the coinbase instead of orphaning allows for 100 blocks'
time for a consensus to be reached, rather than 10 minutes. This
allows for human verification/intervention if needed (orphaning
decisions would almost always need to be automated, due to the short
timeframe). This is a useful insight, and I don't think it's been
brought up before.

2. The original specification of how it's done (redistribution, no
cost to voting) does seem exploitable. This can be fixed by reducing
the incentive (burning instead of redistributing) and/or adding a risk
to the orphaning attempts (a vote that fails destroys X bitcoins'
worth from each voting block's own coinbase). The incentives can be
tailored to mirror those of orphaning a block, to reduce the risk of
abuse. Then the only difference from orphaning are 1) More limited
rewriting of history (only the coinbase, vs all transactions in the
block), and 2) More time to coordinate a response.

3. This proposal may be used for things other than punishing
double-spend pools. In fact it might be used to punish miners for
doing anything a significant percentage of hashpower dislikes (large
OP_RETURNs, large blocks, gambling transactions, transactions banned
by a government). But we can make the threshold higher than 51%, so
that this doesn't turn into a significant risk (if 75% of hashpower is
willing to enforce a rule, we're already likely to see it enforced
through orphaning).

On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi alex.mizr...@gmail.com wrote:


 And it still would. Non-collusive miners cast votes based on the outcome
 of their own attempts to double spend.


 Individually rational strategy is to vote for coinbase reallocation on every
 block.

 Yes, in that case nobody will get reward. It is similar to prisoner's
 dilemma: equilibrium has worst pay-off.
 In practice that would mean that simple game-theoretic models are no longer
 applicable, as they lead to absurd results.


 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.
 Miners that are deliberately trying to double spend are worse than useless.


 Miners work to get rewards.
 It absolutely doesn't matter whether they are deliberately trying to
 double-spend or not: they won't be able to double-spend without a collusion.

 --
 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] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Chris Pacia
What is the advantage of this proposal over just orphaning the block with
double spends?

There's currently a set of rules which government what constitutes a valid
block. Miners don't build on blocks that don't accord with those rules out
of fear that a major won't follow and they will waste hashing power.

If there was a rule supported by the majority that considered blocks with
double spends (defined in some fashion) as invalid miners wouldn't build on
them for the same reason they wouldn't build on a block with a coinbase
over 25 btc, say. It seems that would accomplish the same without the other
issues.
On Apr 23, 2014 12:04 PM, Christophe Biocca christophe.bio...@gmail.com
wrote:

 It's not necessary that this coinbase retribution be either
 profitable or risk-free for this scheme to work. I think we should
 separate out the different layers of the proposal:

 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
 time for a consensus to be reached, rather than 10 minutes. This
 allows for human verification/intervention if needed (orphaning
 decisions would almost always need to be automated, due to the short
 timeframe). This is a useful insight, and I don't think it's been
 brought up before.

 2. The original specification of how it's done (redistribution, no
 cost to voting) does seem exploitable. This can be fixed by reducing
 the incentive (burning instead of redistributing) and/or adding a risk
 to the orphaning attempts (a vote that fails destroys X bitcoins'
 worth from each voting block's own coinbase). The incentives can be
 tailored to mirror those of orphaning a block, to reduce the risk of
 abuse. Then the only difference from orphaning are 1) More limited
 rewriting of history (only the coinbase, vs all transactions in the
 block), and 2) More time to coordinate a response.

 3. This proposal may be used for things other than punishing
 double-spend pools. In fact it might be used to punish miners for
 doing anything a significant percentage of hashpower dislikes (large
 OP_RETURNs, large blocks, gambling transactions, transactions banned
 by a government). But we can make the threshold higher than 51%, so
 that this doesn't turn into a significant risk (if 75% of hashpower is
 willing to enforce a rule, we're already likely to see it enforced
 through orphaning).

 On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi alex.mizr...@gmail.com
 wrote:
 
 
  And it still would. Non-collusive miners cast votes based on the outcome
  of their own attempts to double spend.
 
 
  Individually rational strategy is to vote for coinbase reallocation on
 every
  block.
 
  Yes, in that case nobody will get reward. It is similar to prisoner's
  dilemma: equilibrium has worst pay-off.
  In practice that would mean that simple game-theoretic models are no
 longer
  applicable, as they lead to absurd results.
 
 
  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.
  Miners that are deliberately trying to double spend are worse than
 useless.
 
 
  Miners work to get rewards.
  It absolutely doesn't matter whether they are deliberately trying to
  double-spend or not: they won't be able to double-spend without a
 collusion.
 
 
 --
  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

--
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 Kevin
On 4/23/2014 12:04 PM, Christophe Biocca wrote:
 It's not necessary that this coinbase retribution be either
 profitable or risk-free for this scheme to work. I think we should
 separate out the different layers of the proposal:

 1. Attacking the coinbase instead of orphaning allows for 100 blocks'
 time for a consensus to be reached, rather than 10 minutes. This
 allows for human verification/intervention if needed (orphaning
 decisions would almost always need to be automated, due to the short
 timeframe). This is a useful insight, and I don't think it's been
 brought up before.

 2. The original specification of how it's done (redistribution, no
 cost to voting) does seem exploitable. This can be fixed by reducing
 the incentive (burning instead of redistributing) and/or adding a risk
 to the orphaning attempts (a vote that fails destroys X bitcoins'
 worth from each voting block's own coinbase). The incentives can be
 tailored to mirror those of orphaning a block, to reduce the risk of
 abuse. Then the only difference from orphaning are 1) More limited
 rewriting of history (only the coinbase, vs all transactions in the
 block), and 2) More time to coordinate a response.

 3. This proposal may be used for things other than punishing
 double-spend pools. In fact it might be used to punish miners for
 doing anything a significant percentage of hashpower dislikes (large
 OP_RETURNs, large blocks, gambling transactions, transactions banned
 by a government). But we can make the threshold higher than 51%, so
 that this doesn't turn into a significant risk (if 75% of hashpower is
 willing to enforce a rule, we're already likely to see it enforced
 through orphaning).

 On Wed, Apr 23, 2014 at 11:38 AM, Alex Mizrahi alex.mizr...@gmail.com wrote:
 And it still would. Non-collusive miners cast votes based on the outcome
 of their own attempts to double spend.

 Individually rational strategy is to vote for coinbase reallocation on every
 block.

 Yes, in that case nobody will get reward. It is similar to prisoner's
 dilemma: equilibrium has worst pay-off.
 In practice that would mean that simple game-theoretic models are no longer
 applicable, as they lead to absurd results.

 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.
 Miners that are deliberately trying to double spend are worse than useless.

 Miners work to get rewards.
 It absolutely doesn't matter whether they are deliberately trying to
 double-spend or not: they won't be able to double-spend without a collusion.

 --
 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
This all sounds verry restrictive.  Is it possible to do a sweep in 
order to clean up double spending?  Why punish miners for the sake of 
punishing them?


-- 
Kevin


--
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 Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/23/2014 03:07 PM, Mike Hearn wrote:
 On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier
 justusranv...@gmail.comwrote:
 
 If enough miners don't like a block that has been mined, they can
 all work to orphan it without any change to the protocol
 whatsoever.
 
 
 As was already pointed out, yes. However this requires them to
 immediate establish a majority consensus and be absolutely sure it
 really is the majority. You suggest an out of band mechanism for
 that, but why is this better than using the actual consensus
 mechanism you're trying to measure?
 
 
 Once you've changed the network such that it is no longer a
 machine that faithfully processes scripts
 
 
 Bitcoin imposes far more rules than just execution of the
 scripting language, many of which are entirely arbitrary and the
 result of (controversial) human judgement, like the inflation
 schedule. You can't claim Bitcoin implements only some kind of
 natural law.
 

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:

http://bitcoinism.blogspot.com/2014/04/dirty-deals-in-smoke-filled-rooms.html

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTV/Y0AAoJECoisBQbQ4v08NcH/RfkaBAcS5eAKmwePqFuqIUN
xJKyIWo+tyY1vPYgArCVNsYr3YM8Wc5fkpqLNxCaM7S0/UmO8YaOdiD7XJyl7bF9
xAveyRt1mfHhx9x6hnPLYbe8WKqtjssSt6MglN8OXtf0EDO+eIxPj6Ya8OZ5YJrL
N8SMHaDs2J+qy3Qfec9keE5dyhYLNRC6PjYPVvrRAyqFSjt/8r4Z2a4r0oqvv3Yt
mYU1Tx+WoXMKXWY/Dwql1NLbuspZsOhPx/ncROZ5KVryCdrcW/GEIEQ6P0AIdHvT
TKYJzh1bdRDYDmVS5z8nUG6waxJwuWPStQo7UYdg26daRUw5qPzjO9SMLLFZPCU=
=OOck
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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-23 Thread Pieter Wuille
On Tue, Apr 8, 2014 at 5:41 PM, slush sl...@centrum.cz wrote:
 I've discussed the solution of Litecoin seed in BIP32 HMAC with Litecoin
 devs already, and after long discussion we've concluded that it is generally
 bad idea.

 When changing Bitcoin seed constant to something different, same *entropy*
 will produce different *master node*. That's actually the opposite what's
 requested, because xprv serialization format stores *node*, not *entropy*.
 By changing HMAC constant, you still won't be able to store one node and
 derive wallets for multiple coins at same time.

Storing the seed is superior to storing the master node already
(whether coin specific or not), as it is smaller.

All this changes is making the seed the super master which allows
generating the coin-specific masters (which get an actual useful
function: revealing your entire-tree, but only one coin's subset of
it).

 * Every encoded node (including master nodes) has a chain-specific
 serialization magic.

 This is in practice almost the same as your suggestion, except that
 the m/cointype' in m/cointype'/account'/change/n is replaced by
 different masters. The only disadvantage I see is that you do not have
 a way to encode the super master that is the parent of all
 chain-specific masters. You can - and with the same security
 properties - encode the seed, though.


 Actually I don't understand why there's such disagreement about cointype
 level here, what it breaks? I see it as the cleanest solution so far. It is
 forward and backward compatible, does need any special extension to bip32
 (to be strict, bip32 says Bitcoin seed, so client using Litecoin seed
 cannot be bip32 compatible).

Fair enough, it would break strictly BIP32. Then again, BIP32 is a
*Bitcoin* improvement proposal, and not something that necessarily
applies to other coins (they can adopt it of course, I don't care).

What I dislike is that this removes the ability of using the magic in
the serialization to prevent importing a chain from the wrong coin.
The standard could just say that instead of Bitcoin seed, you'd use
Coin seed:  + magic, so you don't need an extra mapping from
cointype to seed strings.

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


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] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/23/2014 05:47 PM, Gavin Andresen wrote:
 And why do you think your blog is more public than this open,
 publicly archived mailing list???
 

Non-developers are more comfortable using social media tools. Blog
posts can be shared, Tweeted, and commented upon using nothing more
than a web browser.

The barrier to participation on a mailing list is higher, and the
visibility is lower.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTV/0yAAoJECoisBQbQ4v0Fm8H/j0fG7s/iEQUDlV2+5mxeiBO
eoPY2gwuDSTjXc74/3olPHrL/BTGtGg90zwFmlwruUJOaW2m3xvbTD78S8e3HmCC
fqqFKQLg+gOQYud2oiHVNW6H++QqKgSJXu4Lr87ZTkpiRGTgr5PWyhe+4sLeXxam
InqcFmtTHiUMKlmiPj/FUaPHxYT+n+FaPuiZRUYt0Wfxcc9b1n6gEpV7r36Wh8gl
e3rMeDwTfsj/0R4+E+oFEgPl7XBGIJWAf4Nzebuog4ABlqzm4B/RlclZ/5N3W2zZ
6ym6dGpFwN+RuDY2/S2kah6dAeKyk2mAsAChoSOj+vfhCW9wKzclVyM2FNV6lwE=
=djWj
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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 Mike Hearn

 Non-developers are more comfortable using social media tools. Blog
 posts can be shared, Tweeted, and commented upon using nothing more
 than a web browser.


I don't think Twitter is an appropriate medium for discussing the details
of byzantine consensus algorithms.

I'm not going to bother arguing in replies to a blog post. Suffice it to
say, miners are already handsomely compensated via both inflation and fees
for doing their job of preventing double spends. Your suggestion is people
should pay them EVEN MORE for simply not being corrupt. My proposal is
simpler - how about we find the ones that are claiming people's money via
coinbases yet not doing their jobs correctly, and take the money back (or
destroy it). I think I prefer that one. Miners that are maliciously double
spending cannot justify their existence, they offer no useful service and
do not deserve compensation as a result.
--
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-23 Thread slush
On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille pieter.wui...@gmail.comwrote:

 Storing the seed is superior to storing the master node already
 (whether coin specific or not), as it is smaller.


...Except that you're loosing flexibility (serialization, deserialization)
which gives you BIP32 node.

I see bip32 seed as some transitional, internal state from raw entropy to
bip32 master node and this seed should not be handled by the end user in
any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
mnemonic format) can be used very widely and have no downsides against
using raw bip32 seed.



 Fair enough, it would break strictly BIP32. Then again, BIP32 is a
 *Bitcoin* improvement proposal, and not something that necessarily
 applies to other coins (they can adopt it of course, I don't care).


I also don't care too much about altcoins, but people want them so me, as
infrastructure developer, need to think about it. And I don't see any
reason for breaking compatibility between Bitcoin and other altcoins. I
would be happier if there will be another sentence than Bitcoin seed, but
honestly, who cares. It is just some magic string for hashing the raw
seed...


 What I dislike is that this removes the ability of using the magic in
 the serialization to prevent importing a chain from the wrong coin.


The truth is that even existing software which handle bip32 don't care
about 'version' at all. I think that xpub/xprv distinction is the only
useful feature of version, so user se if it stores public or private
information.

But using prefixes which doesn't enforce anything is even more dangerous.
If somebody exports node dogeblablabla, it creates false exceptations
that there's only dogecoin stored.

 Marek
--
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-23 Thread Pavol Rusnak
On 04/23/2014 08:39 PM, Tier Nolan wrote:
 A merchant could easily send 20 addresses in a row to customers and none of
 them bother to actually buy anything.

Such merchant would surely use some merchant system instead of generic
wallet software.

 Setting the gap limit to high is just a small extra cost in that case.

Not if you have 100 accounts on 10 different devices.

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

--
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-23 Thread Tamas Blummer
The most useful meta data to optimize chain scan is the key birth date, then 
the allowed gap size. 

Tamas Blummer
http://bitsofproof.com

On 23.04.2014, at 20:39, Tier Nolan tier.no...@gmail.com wrote:

 Different users could have different gap limit requirements.  20 seems very 
 low as the default.
 
 A merchant could easily send 20 addresses in a row to customers and none of 
 them bother to actually buy anything.
 
 Setting the gap limit to high is just a small extra cost in that case.
 
 Bip-32 serialization doesn't have a way of adding meta data though.
 
 



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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 Justus Ranvier
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/23/2014 06:37 PM, Mike Hearn wrote:
 If you want to try and argue that the development list is the wrong
 place to discuss development, please do so on another thread (or
 your blog). Let's keep this thread for discussion of the original
 proposal - ideally, discussed with the dryness that a topic as
 nerdy as distributed consensus algorithms deserves ;)
 

Is that what you say to yourself to quiet your conscience at night
(assuming you're one of the non-sociopathic humans who does indeed
have one)? It's just a nerdy distributed consensus problem?

The things you're talking about fucking around with have real life
implications for quite a few people and your casual dismissal of this
is precisely why I responded in the way that I did.

What you're doing is reckless endangerment and you're not got to get
away with brushing it off as a mere technical detail.

Sunlight is the best disinfectant, and this episode is demonstrating
to the world exactly how averse you are do that kind of transparency.

- -- 
Support online privacy by using email encryption whenever possible.
Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd
3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1
V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY
QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N
aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU
ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ=
=L5nX
-END PGP SIGNATURE-


0x1B438BF4.asc
Description: application/pgp-keys
--
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 Gregory Maxwell
On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn m...@plan99.net wrote:
 Lately someone launched Finney attacks as a service (BitUndo). As a reminder
 for newcomers, Finney attacks are where a miner secretly works on a block
 containing a double spend.

Hm? I didn't think this is at all what they did.  What they claim to
do is to prioritize transactions in their mempool from people who pay
them, potentially over and above other transactions which they may or
may not have received first.

This may still be bad news for someone taking an irreversible action
in response to an unconfirmed payment and it may or may not be really
ill advised in general, but I think it's less sinister than it sounds
in your posts.  Is there some reason to believe it isn't what it
claims to be?

I think we have very clear evidence that the Bitcoin community doesn't
care if miners reorder transactions in their mempool to profitable
ends: In https://bitcointalk.org/index.php?topic=327767.0 it's
demonstrated that GHash.IO, currently the largest publicly identified
pool was used to rip off Betcoin dice via double-spends.

 first started using Bitcoin, nowadays most of my purchases with it are for
 food and drink. If Bitcoin could not support such purchases, I would use it
 much less.

Accepting zero-conf inherently has some risk (well, so does all
business, but there is substantially more in a zero-conf payment).
Even in a spherical-cow Bitcoin absent anything like Bitundo someone
can just give a double spend to a large miner and currently give the
whole rest of the network the one paying the merchant.  They will,
with high success rate be successful.   Worse, it may _appear_ to the
network that the miner was a bitundo but they really were not.   The
blockchain exists to establish consensus ordering, prior to the
blockchain there is no order, and so it is not easy to really say
which transaction came first in any meaningful sense.

But in business we balance risks and the risk that sometimes a
transaction will be reversed exists in every electronic payment system
available today, in most of them the risk persists for _months_ rather
than minutes.  Businesses can still operate in the face of these
risks.

More importantly, it's possible to deploy technological approaches to
make zero-conf very secure against reversal: Things like performing
multi-sig with a anti-double-spending system, or using an external
federated payment network... but this stuff requires substantial
development work— though it's not work thats likely to happen if
people are still confused about the level of security that zero-conf
has.

 Miners can vote to reallocate the coinbase value of bad blocks before they
 mature.

I think miners 'voting' to reallocate coins, even if they're
thoroughly convinced that the owner of the coins is a nasty party, is
a much greater violation of the Bitcoin social contract than some
twiddling with the unspecified unconfirmed transaction ordering.

Doubly so because a 'nasty' party with non-trivial hash-power can
doublespend their own transactions with a pretty good success rate (as
was the case for the GHash.io betcoin spends) including not-just
zero-conf (though with obviously reduced effectiveness), and all of
your reliable detection depends on it being a public service.

A much better defense is having the control of hash power very well
distributed and so there isn't any central point that excerts enough
influence to change the risk statistics much.  Giving miners the
ability to steal each others payments is, if anything, a force away
from that decentralization.

--
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-23 Thread Tier Nolan
On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak st...@gk2.sk wrote:


  Setting the gap limit to high is just a small extra cost in that case.

 Not if you have 100 accounts on 10 different devices.


I meant for a merchant with a server that is handing out hundreds of
addresses.

The point is to have a single system that is compatible over a large number
of systems.
--
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 Drak
Cut it out with the ad hominem attacks please. If you cant be civil, please
go away until you learn some manners.

I think the issue being discussed is do you orphan an entire block causing
distress to users as well, or try to just cause distress just to the evil
miner? This discussion is about exploring the ramifications of all these
options.

I think you are also forgetting that, miners can implement their own
filters and behaviours without anyone's consent. So having an open
discussion and exploring all possibilities can only be a good thing before
someone goes off an implements a change without taking into account other
points of view they may not have considered yet.
 On 23 Apr 2014 19:51, Justus Ranvier justusranv...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 04/23/2014 06:37 PM, Mike Hearn wrote:
  If you want to try and argue that the development list is the wrong
  place to discuss development, please do so on another thread (or
  your blog). Let's keep this thread for discussion of the original
  proposal - ideally, discussed with the dryness that a topic as
  nerdy as distributed consensus algorithms deserves ;)
 

 Is that what you say to yourself to quiet your conscience at night
 (assuming you're one of the non-sociopathic humans who does indeed
 have one)? It's just a nerdy distributed consensus problem?

 The things you're talking about fucking around with have real life
 implications for quite a few people and your casual dismissal of this
 is precisely why I responded in the way that I did.

 What you're doing is reckless endangerment and you're not got to get
 away with brushing it off as a mere technical detail.

 Sunlight is the best disinfectant, and this episode is demonstrating
 to the world exactly how averse you are do that kind of transparency.

 - --
 Support online privacy by using email encryption whenever possible.
 Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (GNU/Linux)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd
 3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1
 V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY
 QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N
 aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU
 ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ=
 =L5nX
 -END PGP 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


--
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-23 Thread Tamas Blummer
I built such a merchant system handing out BIP32 addresses. 

The gap size problem does not arise there since such a system has to have an 
extra database keeping track of requests, so there is no added cost of storing 
the key coordinates used by them. A scan is not needed the keys can be accessed 
at random order.

Tamas Blummer
http://bitsofproof.com

On 23.04.2014, at 21:00, Tier Nolan tier.no...@gmail.com wrote:

 On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak st...@gk2.sk wrote:
 
  Setting the gap limit to high is just a small extra cost in that case.
 
 Not if you have 100 accounts on 10 different devices.
 
 I meant for a merchant with a server that is handing out hundreds of 
 addresses.
  
 The point is to have a single system that is compatible over a large number 
 of systems.



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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-23 Thread slush
Using higher gap limit in the software is not prohibited, but then it
breaks the standard as is, in mean that importing such wallet to another
BIP64 wallet won't recover the funds properly, without proper settings of
gap limit...

Gap limit 20 is the most sane defaults for majority of users (actually I
think it is a bit higher than is really necessary for 99% users) and
majority of users won't need to change it at any time.

Marek


On Wed, Apr 23, 2014 at 9:00 PM, Tier Nolan tier.no...@gmail.com wrote:

 On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak st...@gk2.sk wrote:


  Setting the gap limit to high is just a small extra cost in that case.

 Not if you have 100 accounts on 10 different devices.


 I meant for a merchant with a server that is handing out hundreds of
 addresses.

 The point is to have a single system that is compatible over a large
 number of systems.


 --
 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] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Mike Hearn
On Wed, Apr 23, 2014 at 8:57 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 Hm? I didn't think this is at all what they did.  What they claim to
 do is to prioritize transactions in their mempool from people who pay
 them


That's the definition of a Finney attack, right? A tx is broadcast and
nodes normally take the first one they saw, allowing you to measure
propagation and use double spend alerts to get pretty good confidence,
pretty quick. A Finney attacker doesn't do that and includes a double
spend, so the one in the mempool gets overridden.

I mean, I hope that's the definition of a Finney attack, given that I
coined the term :)


 I think we have very clear evidence that the Bitcoin community doesn't
 care if miners reorder transactions in their mempool to profitable
 ends: In https://bitcointalk.org/index.php?topic=327767.0 it's
 demonstrated that GHash.IO, currently the largest publicly identified
 pool was used to rip off Betcoin dice via double-spends.


Yes, very disappointing. Though I'd hope that if this sort of thing was
sustained over months and merchants started dropping Bitcoin as a result,
miners would pay more attention.

Right now I suspect miners don't pay attention to anything other than
hardware builds though.

Yes, Bitcoin is imperfect at stopping double spends today. It can certainly
be improved! There are plenty of oft-discussed measures like double spend
alerts and discouraging Finney-attack blocks as was debated extensively in
2011. This thread is just a third such proposal.

More importantly, it's possible to deploy technological approaches to
 make zero-conf very secure against reversal: Things like performing
 multi-sig with a anti-double-spending system


These sorts of proposals are all just ways of saying block chains kind of
suck and we should go back to using trusted third parties.

That may well be how the Bitcoin experiment ends, but I think we all agree
here that block chains and decentralised consensus are quite spiffy and we
should try hard to make them work as well as possible before just shrugging
and say find a trusted third party. Otherwise why not just go back to
using MasterCard? Any TTP that enforces anti double spending rules will be
a lot more centralised than miners, given the difficulty of finding them,
their need for a strong brand/reputation, and the difficulty of getting
everyone to agree on them.

Not to mention that this solution makes Bitcoin sound like a joke currency.
It's a super duper low fee totally decentralised financial system .
unless you want to buy something in, you know, a shop. And walk out. Then
you need to sign up with this company that looks suspiciously like a bank,
and pay their fees, and yeah there's like 3 to pick from. Totally
decentralised!


 Doubly so because a 'nasty' party with non-trivial hash-power can
 doublespend their own transactions


If a miner is vertically integrated and defrauding merchants themselves,
with no service component, pretty quickly people would talk to each other,
notice this pattern and stop trading with them, making their coins rather
useless. Also if their real identity is ever revealed they could be liable
and there'd be a lot of people wanting to sue them.

So I think the ability to resell double spending to lots of different
people around the world seems important to practicality.
--
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-23 Thread Pavol Rusnak
On 04/23/2014 09:00 PM, Tier Nolan wrote:
 The point is to have a single system that is compatible over a large number
 of systems.

There is such system and it is called BIP32.

On the other hand, in BIP64 we try to put a set of restrictions and
rules on top of BIP32. There will always be some special usecases where
BIP64 is not a good fit and there's no reason why you cannot use BIP32
in a different manner using a different purpose field.

Examples: Electrum does not want to use accounts and they start to use
scheme m/65'/change/address (where change = 0 or 1). Or Andreas
Schildbach wants to have refunds chain so he uses m/66'/chain/address
(where chain = 0, 1 or 2).

We wanted to find one good solution that fits all, but unfortunately it
turned out everyone wants something a little bit different.

The point of the whole effort is that you can have ONE SINGLE BACKUP
(master node) for all these independent purposes and suddenly claims
such as my wallet is BIP64 and BIP66 compatible actually mean
something as opposed to BIP32 compatible which actually means nothing
except that the wallet author is capable of using HMAC in context of
generating the tree.

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

--
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-23 Thread Tamas Blummer
Pieter suggested in IRC couple of months ago to append key birth to key 
serialization in xprv….@unixtime format.

What about picking this idea up in BIP64? It would greatly help the importing 
client.

Regards,

Tamas Blummer
http://bitsofproof.com




signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
 On 04/23/2014 09:00 PM, Tier Nolan wrote:
  The point is to have a single system that is compatible over a large
  number of systems.
 
 There is such system and it is called BIP32.
 
 On the other hand, in BIP64 we try to put a set of restrictions and
 rules on top of BIP32. There will always be some special usecases where
 BIP64 is not a good fit and there's no reason why you cannot use BIP32
 in a different manner using a different purpose field.
 
 Examples: Electrum does not want to use accounts and they start to use
 scheme m/65'/change/address (where change = 0 or 1). Or Andreas
 Schildbach wants to have refunds chain so he uses m/66'/chain/address
 (where chain = 0, 1 or 2).
 
 We wanted to find one good solution that fits all, but unfortunately it
 turned out everyone wants something a little bit different.

Why do clients need to use the features in BIP 64? If Electrum doesn't want to 
use accounts, then it can just use account 0 for everything. Refund chains are 
definitely a third case that should be added to the external and 
internal/change address division... and a wallet not implementing refund 
addresses would simply not use that chain.

Luke

--
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 Sergio Lerner
(this e-mail is cc to the bitcoin-research list)

Hi everyone from the bitcoin-development mailing list!
I decided to join this legendary list because it seems that all the
research fun is taking place in here, and I don't want to miss the
research party.

Regarding the discussion about BitUndo, a year ago I posted about an
attack (which I called the the Bitcoin Eternal Choice for the Dark Side
Attack or ECDSA)
that tries to erode the confidence in Bitcoin by offering double-spends
as a service.

I think it's related to the last post from Peter Todd about the problems
with BitUndo.

Here is the link if anyone is interested in reading about it...
http://bitslog.wordpress.com/2013/06/26/the-bitcoin-eternal-choice-for-the-dark-side-attack-ecdsa/

Sergio D. Lerner.



On 23/04/2014 12:29 p.m., Peter Todd wrote:
 Interesting discussion re: incentive compatibility happening on the
 bitcoin-development email list:

 - Forwarded message from Mike Hearn m...@plan99.net -

 Date: Wed, 23 Apr 2014 09:55:30 +0200
 From: Mike Hearn m...@plan99.net
 To: Bitcoin Dev bitcoin-development@lists.sourceforge.net
 Subject: [Bitcoin-development] Coinbase reallocation to discourage Finney 
 attacks

 Lately someone launched Finney attacks as a service (BitUndo). As a
 reminder for newcomers, Finney attacks are where a miner secretly works on
 a block containing a double spend. When they eventually find a block, they
 run to the merchant and pay, then broadcast the block. In a simpler variant
 of this attack you make purchases as normal with a modified wallet that
 always submits a double spend to the service, and then N% of the time where
 N is the percentage of overall hash power the dishonest miners have, you
 get your money back minus their fee.

 N does not need to be very high to render Bitcoin much less useful. Real
 time transactions are very important. Although I never expected it when I
 first started using Bitcoin, nowadays most of my purchases with it are for
 food and drink. If Bitcoin could not support such purchases, I would use it
 much less.
 Even with their woeful security many merchants see 1-2% credit card
 chargeback rates, and chargebacks can be disputed. In fact merchants win
 about 40% of chargeback disputes. So if N was only, say, 5%, and there was
 a large enough population of users who were systematically trying to
 defraud merchants, we'd already be having worse security than magstripe
 credit cards. EMV transactions have loss rates in the noise, so for
 merchants who take those Bitcoin would be dramatically less secure.

 The idea of discouraging blocks that perform Finney attacks by having
 honest miners refuse to build on them has been proposed. But it has a
 couple of problems:

1. It's hard to automatically detect Finney attacks. Looking for blocks
that contain unseen transactions that override the mempool doesn't work -
the dishonest users could broadcast all their double spends once a Finney
block was found and then broadcast the block immediately afterwards, thus
making the block look like any other would in the presence of double 
 spends.

2. If they could be automatically identified, it possibly could be
converted into a DoS on the network by broadcasting double spends in such a
way that the system races, and every miner produces a block that looks like
a Finney attack to some of the others. The chain would stop advancing.

3. Miners who want to vote no on a block take a big risk, they could
be on the losing side of the fork and end up wasting their work.

 We can resolve these problems with a couple of tweaks:

1. Dishonest blocks can be identified out of band, by having honest
miners submit double spends against themselves to the service anonymously
using a separate tool. When their own double spend appears they know the
block is bad.

2. Miners can vote to reallocate the coinbase value of bad blocks before
they mature. If a majority of blocks leading up to maturity vote for
reallocation, the value goes into a pot that subsequent blocks are allowed
to claim for themselves. Thus there is no risk to voting no on a block,
the work done by the Finney attacker is not wasted, and users do not have
to suffer through huge reorgs.

 This may seem a radical suggestion, but I think it's much less radical than
 some of the others being thrown around.

 The above approach works as long as the majority of hashpower is honest,
 defined to mean, working to stop double spending. This is the same security
 property as described in the white paper, thus this introduces no new
 security assumptions. Note that assuming *all* miners are dishonest and are
 willing to double spend automatically resolves the Bitcoin experiment as a
 failure, because that would invalidate the entire theory upon which the
 system is built. That doesn't mean the assumption is wrong! It may be that
 an entirely unregulated market for double 

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 09:44 PM, Luke-Jr wrote:
 Why do clients need to use the features in BIP 64? If Electrum doesn't want 
 to 
 use accounts, then it can just use account 0 for everything. Refund chains 
 are 

As Andreas wrote earlier in this thread: There is no bare minimum.
Either you implement the BIP fully or not.

What you suggest does not follow the principle of least surprise.
Suppose user imports his BIP64 compatible wallet into Electrum, which
claims it is BIP64 compatible, but actually implements just a subset of
the spec (sticking account index to 0). The user now sees just a
fraction of his coins and is puzzled.

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

--
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-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:49:38 PM Pavol Rusnak wrote:
 On 04/23/2014 09:44 PM, Luke-Jr wrote:
  Why do clients need to use the features in BIP 64? If Electrum doesn't
  want to use accounts, then it can just use account 0 for everything.
  Refund chains are
 
 As Andreas wrote earlier in this thread: There is no bare minimum.
 Either you implement the BIP fully or not.
 
 What you suggest does not follow the principle of least surprise.
 Suppose user imports his BIP64 compatible wallet into Electrum, which
 claims it is BIP64 compatible, but actually implements just a subset of
 the spec (sticking account index to 0). The user now sees just a
 fraction of his coins and is puzzled.

Any wallet should import all the coins just fine, it just wouldn't *use* any 
account other than 0. Remember addresses are used to receive bitcoins; once 
the UTXOs are in the wallet, they are no longer associated with the address or 
any other details of how they were received.

Luke

--
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-23 Thread slush
On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote:

 Any wallet should import all the coins just fine, it just wouldn't *use*
 any
 account other than 0. Remember addresses are used to receive bitcoins; once
 the UTXOs are in the wallet, they are no longer associated with the
 address or
 any other details of how they were received.


Wallet don't see UTXO until it scans all branches/accounts on HD node
import.
--
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 Mike Hearn

 What you're talking about is just disagreement about the content of
 the memory pool


That's the same thing. Whilst you're mining your double spend tx, it's in
your mempool but you don't broadcast it as per normal. Then when you find
the block you broadcast it to override everyone elses mempool. So yours and
theirs were inconsistent.

The only slight way BitUndo differs is, they provide it as a service, and I
don't know if they inform you when they found a block (probably not), so
you have to do the purchase and then hope BitUndo finds the next block.
Otherwise the purchase clears. But they could certainly add a
pre-notification before they broadcast to get back to the exact scheme
originally described, they have everything else in place.


 Oscar himself can be implemented as a majority M parties to further
 increase confidence


This just brings us back to square one. Who are these parties and what if I
pay them to be corrupt? What if they offer to be corrupt as a service?

Let's say I succeed in finding some parties who are incorruptible no matter
how large of a percentage I offer them. At this point, why bother with
miners at all? Why pay for double spend protection twice, once to a group
of Oscar's who are trustworthy and once to a group of miners who are not?

The point of the broadcast network and mining is so there can be lots of
Oscar's and I don't have to know who they are or sign up with them or put
any effort into evaluating their reputation.


 value retail transactions— the fact that any cheating by oscar is
 cryptographically provable (just show them the double signatures)
 maybe be strong enough alone.


But as you point out, cheating my GHash.io did not result in any obvious
negative consequence to them, despite that preventing double spending is
their sole task. Why would Oscar be different to GHash.io?

Trying to solve the problem of dishonest miners is effectively trying to
solve the automatically find trusted third parties problem at scale.
--
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-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:57:46 PM slush wrote:
 On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote:
  Any wallet should import all the coins just fine, it just wouldn't *use*
  any
  account other than 0. Remember addresses are used to receive bitcoins;
  once the UTXOs are in the wallet, they are no longer associated with the
  address or
  any other details of how they were received.
 
 Wallet don't see UTXO until it scans all branches/accounts on HD node
 import.

Yes, it should scan all possible (under the BIP-defined structure) branches 
regardless of which features it supports.

Luke

--
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-23 Thread Tamas Blummer

On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote:
 Any wallet should import all the coins just fine, it just wouldn't *use* any 
 account other than 0. Remember addresses are used to receive bitcoins; once 
 the UTXOs are in the wallet, they are no longer associated with the address 
 or 
 any other details of how they were received.

This is a bit idealistic. 
The wallet has to know how it got the UTXO in order to be able to spend it.


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
 On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote:
  Any wallet should import all the coins just fine, it just wouldn't *use*
  any account other than 0. Remember addresses are used to receive
  bitcoins; once the UTXOs are in the wallet, they are no longer
  associated with the address or any other details of how they were
  received.
 
 This is a bit idealistic.
 The wallet has to know how it got the UTXO in order to be able to spend it.

No it doesn't... Just the assigned scriptPubKey and secret(s) required to 
satisfy 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] New BIP32 structure

2014-04-23 Thread Tamas Blummer
On 23.04.2014, at 22:02, Luke-Jr l...@dashjr.org wrote:

 On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
 On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote:
 Any wallet should import all the coins just fine, it just wouldn't *use*
 any account other than 0. Remember addresses are used to receive
 bitcoins; once the UTXOs are in the wallet, they are no longer
 associated with the address or any other details of how they were
 received.
 
 This is a bit idealistic.
 The wallet has to know how it got the UTXO in order to be able to spend it.
 
 No it doesn't... Just the assigned scriptPubKey and secret(s) required to 
 satisfy it.
 

To know the secret it needs to know which key coordinate to use that is 
logically the same as knowing the address it used to receive it.


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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-23 Thread Pavol Rusnak
On 04/23/2014 10:01 PM, Luke-Jr wrote:
 Yes, it should scan all possible (under the BIP-defined structure) branches 
 regardless of which features it supports.

So you suggest to scan for accounts, show balances but don't allow user
to spend them? Does not seem right to me.

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

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

2014-04-23 Thread Kristov Atlas

On 04/22/2014 09:30 AM, Warren Togami Jr. wrote:
Bitcoin-Translators mailing list is an announce-only mailing list for 
developers to communicate to translators at particular times when new 
translations are needed.  Replies and discussion would go to the 
bitcoin dev list.  Subscriptions to this list would additionally be 
valuable to the project as it allows for a convenient way to ask for 
translations of other related projects like bitcoin.org 
http://bitcoin.org that are hosted on theTransifex platform. 
 Whenever source strings of significance are changed or deadlines are 
announced, translators will learn of work to be done in Transifex 
quickly as they will all be subscribed to this announce list. 
 Discussion of translation issues should be on the Bitcoin-Development 
list.


Development Roadmap of Bitcoin Core 0.9.2

The Bitcoin Core developers have a desire to do a mostly bug-fix and 
translation update release in v0.9.2. A feature and string freeze will 
start about 3 weeks from now.



The purpose of this development roadmap is to communicate the project 
intent and to better organize volunteers. Hopefully doing so will make 
clear when particular types of contributions are most welcome and help 
to push the release process forward in a more timely manner while also 
improving the quality of the release.  Missing a target goal is OK. 
The developers may decide to delay particular goals if there are good 
reasons on a case-by-case basis. While schedules may slip, it is 
generally a good thing for a goal to have existed.



Schedule (subject to change)

13 May 2014:Feature freeze.  Source string freeze.  Release candidate.

20 May 2014: Testing of a release candidate is roughly a week. More 
time can be added at the discretion of the developers to allow for 
testing if further release candidates are deemed necessary due to 
subsequent changes.



Nightly Gitian Builds

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

To make it easier for non-developers and translators to get involved 
in testing unofficial deterministic nightly builds are now available.



Warren Togami


I see that the latest nightly build (thanks for that, Warren) is still 
not compatible with Tails/Debian Squeeze. Is there still an intention to 
address this issue? Might it be fixed by 0.9.2?
--
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-23 Thread Pieter Wuille
That's the point. BIP64 specifies such a structure, and you have to scan
all that it defines.

If you want to write wallet software that does not have the complexity to
deal with just one account, it is not BIP64 compliant. It could try to
define its own purpose system, with a hierarchy without accounts in it. I'm
not sure this is a very interesting use case, but I like how strict it is.
Construction of related chains for multisig addresses is perhaps a better
example of a different purpose structure.
 On 23 Apr 2014 22:03, Luke-Jr l...@dashjr.org wrote:

 On Wednesday, April 23, 2014 7:57:46 PM slush wrote:
  On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote:
   Any wallet should import all the coins just fine, it just wouldn't
 *use*
   any
   account other than 0. Remember addresses are used to receive bitcoins;
   once the UTXOs are in the wallet, they are no longer associated with
 the
   address or
   any other details of how they were received.
 
  Wallet don't see UTXO until it scans all branches/accounts on HD node
  import.

 Yes, it should scan all possible (under the BIP-defined structure) branches
 regardless of which features it supports.

 Luke


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

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
 On 04/23/2014 10:01 PM, Luke-Jr wrote:
  Yes, it should scan all possible (under the BIP-defined structure)
  branches regardless of which features it supports.
 
 So you suggest to scan for accounts, show balances but don't allow user
 to spend them? Does not seem right to me.

Scan all branches for UTXOs, then you have the balance for the wallet. Account 
balances are metadata, so cannot be known from the seed alone. If you want to 
have a way to restore accounts, you must define some more detailed wallet file 
format (which could be built on top of this).

On Wednesday, April 23, 2014 8:04:35 PM you wrote:
 On 23.04.2014, at 22:02, Luke-Jr l...@dashjr.org wrote:
  On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
  The wallet has to know how it got the UTXO in order to be able to spend
  it.
  
  No it doesn't... Just the assigned scriptPubKey and secret(s) required to
  satisfy it.
 
 To know the secret it needs to know which key coordinate to use that is
 logically the same as knowing the address it used to receive it.

Sure, it *knows* what address was used to receive it. But at the point it's a 
UTXO, that address is no longer relevant.

Luke

--
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-23 Thread Pieter Wuille
I believe Luke means scanning chains as defined by the structure, but not
handing out addresses from other accounts than the first one.

That's certainly a possibly way to compatibly implement BIP64, but it
doesn't reduce all that much complexity. I hope people would choose that
over defining their own accountless structure though.
On 23 Apr 2014 22:06, Pavol Rusnak st...@gk2.sk wrote:

 On 04/23/2014 10:01 PM, Luke-Jr wrote:
  Yes, it should scan all possible (under the BIP-defined structure)
 branches
  regardless of which features it supports.

 So you suggest to scan for accounts, show balances but don't allow user
 to spend them? Does not seem right to me.

 --
 Best Regards / S pozdravom,

 Pavol Rusnak st...@gk2.sk


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

2014-04-23 Thread Tamas Blummer
On 23.04.2014, at 22:09, Luke-Jr l...@dashjr.org wrote:

 On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
 On 04/23/2014 10:01 PM, Luke-Jr wrote:
 Yes, it should scan all possible (under the BIP-defined structure)
 branches regardless of which features it supports.
 
 So you suggest to scan for accounts, show balances but don't allow user
 to spend them? Does not seem right to me.
 
 Scan all branches for UTXOs, then you have the balance for the wallet. 
 Account 
 balances are metadata, so cannot be known from the seed alone. If you want to 
 have a way to restore accounts, you must define some more detailed wallet 
 file 
 format (which could be built on top of this).
 
 On Wednesday, April 23, 2014 8:04:35 PM you wrote:
 On 23.04.2014, at 22:02, Luke-Jr l...@dashjr.org wrote:
 On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
 The wallet has to know how it got the UTXO in order to be able to spend
 it.
 
 No it doesn't... Just the assigned scriptPubKey and secret(s) required to
 satisfy it.
 
 To know the secret it needs to know which key coordinate to use that is
 logically the same as knowing the address it used to receive it.
 
 Sure, it *knows* what address was used to receive it. But at the point it's a 
 UTXO, that address is no longer relevant.
 

In context of BIP32 one does not store secrets but re-create them on-the-fly if 
needed using key coordinates known to the UTXO.
Individual secrets per UTXO are about as irrelevant and accessible as addresses.



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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-23 Thread Pavol Rusnak
On 04/23/2014 10:09 PM, Luke-Jr wrote:
 Scan all branches for UTXOs, then you have the balance for the wallet. 
 Account 
 balances are metadata, so cannot be known from the seed alone. If you want to 
 have a way to restore accounts, you must define some more detailed wallet 
 file 
 format (which could be built on top of this).

I think one of the following is happening:

a) you have not read the document
b) you don't understand what accounts are, because you have not read
   the document
c) you don't understand how restoring accounts work, because you
   have not read the document
d) you don't understand that accounts funds are not meant to be mixed
   together, because you have not read the document
e) I got your emails wrong because I am not a native speaker,
   but please read the the document ;-)

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

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

2014-04-23 Thread Wladimir
 I see that the latest nightly build (thanks for that, Warren) is still not
 compatible with Tails/Debian Squeeze. Is there still an intention to address
 this issue? Might it be fixed by 0.9.2?

Can you be more specific as to what problem you're having?

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

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:16:45 PM Pavol Rusnak wrote:
 On 04/23/2014 10:09 PM, Luke-Jr wrote:
  Scan all branches for UTXOs, then you have the balance for the wallet.
  Account balances are metadata, so cannot be known from the seed alone.
  If you want to have a way to restore accounts, you must define some more
  detailed wallet file format (which could be built on top of this).
 
 I think one of the following is happening:
 
 a) you have not read the document
 b) you don't understand what accounts are, because you have not read
the document
 c) you don't understand how restoring accounts work, because you
have not read the document
 d) you don't understand that accounts funds are not meant to be mixed
together, because you have not read the document
 e) I got your emails wrong because I am not a native speaker,
but please read the the document ;-)

You missed one:
f) I missed the part where BIP 32 redefined account to mean subwallet 
instead of what has traditionally been called account in Bitcoin.

:)

In that case, single-subwallet wallet software probably needs to have the user 
provide a subwallet number in addition to the seed.

Luke

--
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-23 Thread Pavol Rusnak
On 04/23/2014 10:32 PM, Luke-Jr wrote:
 f) I missed the part where BIP 32 redefined account to mean subwallet 
 instead of what has traditionally been called account in Bitcoin.

Ah, okay. The last time I saw Bitcoin-qt it was still using independent
addresses.

 In that case, single-subwallet wallet software probably needs to have the 
 user 
 provide a subwallet number in addition to the seed.

Which brings us back to my original complaint that the user can be
confused because he doesn't see all his funds.

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

--
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 Mike Hearn
On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell gmaxw...@gmail.comwrote:

 Right, this works in the Bitcoin network today absent any collusion by
 the miners. You give one miner a transaction and you give every other
 node you can reach another transaction.


Yes, but that can be fixed with double spend alerts.


 Someone you ask to not double spend is an entirely separate matter.
 They aren't self-selecting: you select who you trust to not make
 double spends and there is no need for this trust to be globally
 consistent.


No? It's not just your decision that matters, the receiver also has to
trust them. They're like a dispute mediator in this regard. You can pick
whoever you want, but that doesn't matter if the receiver doesn't recognise
them or trust them. You have to find an overlap to make an instant trade.

In practice if people have to think about this, evaluate brands etc then
you'd get a very small number of parties because the value of global
agreement is so high. Then it becomes hard to remove ones that have a lot
of momentum.

The censorship resistance of the block chain doesn't matter if your double
spending partners refuse to help you spend your money (because they're
being coerced). The censorship can just happen at a different place.


 To stop GHash.io we would have to take away their hardware or change the
 Bitcoin
 protocol to make their hardware useless


. or, have a majority decide to zero out their coinbase rewards for
blocks that double spent against dice sites. That wouldn't undo the double
spend, but you can't do that with the multisig scheme either. All you can
do is punish the corrupted party post-hoc, either by not using them again,
or by unpaying them for the service they did not provide.
--
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

2014-04-23 Thread Warren Togami Jr.
On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas kristovat...@gmail.comwrote:

 I see that the latest nightly build (thanks for that, Warren) is still not
 compatible with Tails/Debian Squeeze. Is there still an intention to
 address this issue? Might it be fixed by 0.9.2?


If I understand the situation, bitcoind does work but not bitcoin-qt due to
qt-4.6?  If that is so, then the official Bitcoin 0.8.6 binaries didn't
work on Squeeze either this is not a regression.

The priority is for bitcoind to work on as many distributions as reasonably
possible as older stable distributions are most often headless.  If you are
a rare user who needs Bitcoin-Qt on an incompatible system you can at least
build it from source.

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-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:35:50 PM Pavol Rusnak wrote:
 On 04/23/2014 10:32 PM, Luke-Jr wrote:
  f) I missed the part where BIP 32 redefined account to mean subwallet
  instead of what has traditionally been called account in Bitcoin.
 
 Ah, okay. The last time I saw Bitcoin-qt it was still using independent
 addresses.

It is. Accounts have been a bitcoind feature since before 0.4.

  In that case, single-subwallet wallet software probably needs to have the
  user provide a subwallet number in addition to the seed.
 
 Which brings us back to my original complaint that the user can be
 confused because he doesn't see all his funds.

I don't see how. The user knows he has money in different subwallets. As long 
as he has a way to specify which subwallet he is accessing in single-subwallet 
clients, there shouldn't be a problem.

Luke

--
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 Adam Ritter
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.


On Wed, Apr 23, 2014 at 10:37 PM, Mike Hearn m...@plan99.net wrote:

 On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell gmaxw...@gmail.comwrote:

 Right, this works in the Bitcoin network today absent any collusion by
 the miners. You give one miner a transaction and you give every other
 node you can reach another transaction.


 Yes, but that can be fixed with double spend alerts.


 Someone you ask to not double spend is an entirely separate matter.
 They aren't self-selecting: you select who you trust to not make
 double spends and there is no need for this trust to be globally
 consistent.


 No? It's not just your decision that matters, the receiver also has to
 trust them. They're like a dispute mediator in this regard. You can pick
 whoever you want, but that doesn't matter if the receiver doesn't recognise
 them or trust them. You have to find an overlap to make an instant trade.

 In practice if people have to think about this, evaluate brands etc then
 you'd get a very small number of parties because the value of global
 agreement is so high. Then it becomes hard to remove ones that have a lot
 of momentum.

 The censorship resistance of the block chain doesn't matter if your double
 spending partners refuse to help you spend your money (because they're
 being coerced). The censorship can just happen at a different place.


 To stop GHash.io we would have to take away their hardware or change the
 Bitcoin
 protocol to make their hardware useless


 . or, have a majority decide to zero out their coinbase rewards for
 blocks that double spent against dice sites. That wouldn't undo the double
 spend, but you can't do that with the multisig scheme either. All you can
 do is punish the corrupted party post-hoc, either by not using them again,
 or by unpaying them for the service they did not provide.



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

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 10:41 PM, Luke-Jr wrote:
 I don't see how. The user knows he has money in different subwallets. As long 
 as he has a way to specify which subwallet he is accessing in 
 single-subwallet 
 clients, there shouldn't be a problem.

Right. But these clients have no right to call themselves BIP64
compatible then.

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

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

2014-04-23 Thread Kristov Atlas

On 04/23/2014 04:39 PM, Warren Togami Jr. wrote:
On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas 
kristovat...@gmail.com mailto:kristovat...@gmail.com wrote:


I see that the latest nightly build (thanks for that, Warren) is
still not compatible with Tails/Debian Squeeze. Is there still an
intention to address this issue? Might it be fixed by 0.9.2?


If I understand the situation, bitcoind does work but not bitcoin-qt 
due to qt-4.6?  If that is so, then the official Bitcoin 0.8.6 
binaries didn't work on Squeeze either this is not a regression.


The priority is for bitcoind to work on as many distributions as 
reasonably possible as older stable distributions are most often 
headless.  If you are a rare user who needs Bitcoin-Qt on an 
incompatible system you can at least build it from source.


Warren


Bitcoin-Qt 0.8.6 worked fine on Tails (and Debian Squeeze, I assume). 
So, it is a regression.


Here's output from the latest nightly build for Linux:

amnesia@amnesia:~/bitcoin-0.9.99.0-20140422-2bbecc8-linux/bin/32$ ./bitcoin-qt
./bitcoin-qt: symbol lookup error: ./bitcoin-qt: undefined symbol: 
_ZN19QAbstractProxyModel11setItemDataERK11QModelIndexRK4QMapIi8QVariantE

Since Tails has many simple development tools like make stripped out 
for security reasons, one could not simply build from source in Tails. 
It might be possible to build in Debian Squeeze and transplant that, 
however. I'll have to give that a shot some time. I'd argue that Tails 
is an incredibly important -- and hardly obscure -- Linux distribution 
that Bitcoin should endeavour to support. See: 
https://tails.boum.org/press/index.en.html


-Kristov
--
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 Gregory Maxwell
On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter 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.

Large scale consensus can't generally provide instantly irreversible
transactions directly: Increasing the block speed can't help past the
point where the time starts getting close to the network diameter...
you simply can't tell what a consensus of a group of nodes is until
several times the light cone that includes all of them.  And if you
start getting close to the limit you dilute the power working on the
consensus and potentially make life easier for a large attacker.

Maybe other chains with different parameters could achieve a different
tradeoff which was better suited to low value retail transactions
(e.g. where you want a soft confirmation fast). A choice of tradeoffs
could be very useful, and maybe you can practically get close enough
(e.g. would knowing you lost a zero-conf double spend within 30
seconds 90% of the time be good enough?)... but I'm not aware of any
silver bullet there which gives you something identical to what a
centralized service can give you without invoking at least a little
bit of centralization.

--
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-23 Thread Pieter Wuille
On Wed, Apr 23, 2014 at 10:43 PM, Pavol Rusnak st...@gk2.sk wrote:
 On 04/23/2014 10:41 PM, Luke-Jr wrote:
 I don't see how. The user knows he has money in different subwallets. As long
 as he has a way to specify which subwallet he is accessing in 
 single-subwallet
 clients, there shouldn't be a problem.

 Right. But these clients have no right to call themselves BIP64
 compatible then.

Would you consider software which scans all accounts as specified by
BIP64, but has no user interface option to distinguish them in any
way, view them independently, and has no ability to keep the coins
apart... compatible with BIP64?

According to the argument here mentioned earlier (all or nothing),
it is, as it will not break interoperability with other BIP64
software. Still, it doesn't support the accounts feature, and perhaps
that's fine?

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


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:43:57 PM Pavol Rusnak wrote:
 On 04/23/2014 10:41 PM, Luke-Jr wrote:
  I don't see how. The user knows he has money in different subwallets. As
  long as he has a way to specify which subwallet he is accessing in
  single-subwallet clients, there shouldn't be a problem.
 
 Right. But these clients have no right to call themselves BIP64
 compatible then.

Then BIP 64 is pretty restrictive. Most end users really have no need for 
subwallet support.

--
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-23 Thread slush
On Wed, Apr 23, 2014 at 10:54 PM, Pieter Wuille pieter.wui...@gmail.comwrote:


 Would you consider software which scans all accounts as specified by
 BIP64, but has no user interface option to distinguish them in any
 way, view them independently, and has no ability to keep the coins
 apart... compatible with BIP64?


No, because one of requirement of BIP64 is to do not mix addressess between
accounts. Without handling those accounts fully, it won't pass this
requirement.

(This level [accounts] splits the key space into independent user
identities, so the wallet never mixes the coins across different accounts.)


Marek
--
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 Daniel Krawisz
The memory pool is just talk. There is no expectation that the memory pool
has to satisfy some standard as to what will eventually exist in the block
chain, and there are any number of ways that people could communicate
transactions to one another without putting them in the memory pool. The
memory pool can't be treated like a contract because there is no
cryptography to enforce it--there is no contract until the transactions
appear in the block chain, inherently.

Mike Hearn's proposal is nonsense because it requires miners to develop a
concensus on which blocks in the block chain are dishonest. There is no way
to prove cryptographically that a block is dishonest because the block
chain itself is the concensus system--before there is concensus, there is
no concept of dishonesty, at least as far as double-spending goes. In order
to decide that a block is dishonest and reallocate the coinbase, a prior
consensus mechanism would be required. Of course, such a consensus
mechanism would also be subject to attacks just like the block chain.

Maxwell's proposal is very good. One only trusts the oscar not to double
spend, which is perfectly reasonable if oscar is a well-known service.
Normal everyday wallets for immediate payments would simply require a
little more infrastructure.

Daniel Krawisz


On Wed, Apr 23, 2014 at 2:59 PM, Mike Hearn m...@plan99.net wrote:

 What you're talking about is just disagreement about the content of
  the memory pool


 That's the same thing. Whilst you're mining your double spend tx, it's in
 your mempool but you don't broadcast it as per normal. Then when you find
 the block you broadcast it to override everyone elses mempool. So yours and
 theirs were inconsistent.

 The only slight way BitUndo differs is, they provide it as a service, and
 I don't know if they inform you when they found a block (probably not), so
 you have to do the purchase and then hope BitUndo finds the next block.
 Otherwise the purchase clears. But they could certainly add a
 pre-notification before they broadcast to get back to the exact scheme
 originally described, they have everything else in place.


 Oscar himself can be implemented as a majority M parties to further
 increase confidence


 This just brings us back to square one. Who are these parties and what if
 I pay them to be corrupt? What if they offer to be corrupt as a service?

  Let's say I succeed in finding some parties who are incorruptible no
 matter how large of a percentage I offer them. At this point, why bother
 with miners at all? Why pay for double spend protection twice, once to a
 group of Oscar's who are trustworthy and once to a group of miners who are
 not?

 The point of the broadcast network and mining is so there can be lots of
 Oscar's and I don't have to know who they are or sign up with them or put
 any effort into evaluating their reputation.


 value retail transactions— the fact that any cheating by oscar is
 cryptographically provable (just show them the double signatures)
 maybe be strong enough alone.


 But as you point out, cheating my GHash.io did not result in any obvious
 negative consequence to them, despite that preventing double spending is
 their sole task. Why would Oscar be different to GHash.io?

 Trying to solve the problem of dishonest miners is effectively trying to
 solve the automatically find trusted third parties problem at scale.


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

2014-04-23 Thread Gregory Maxwell
On Wed, Apr 23, 2014 at 2:18 PM, Luke-Jr l...@dashjr.org wrote:
 How do you get the more expected/usual behaviour of mixing funds between
 accounts? Only a very niche user base needs funds isolated...

Hopefully it would be clarified as only a MUST NOT do so silently...
I have funds split across two wallets and it WONT LET ME SPEND THEM
sounds like a terrible user experience. :)

--
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 Tier Nolan
An interesting experiment would be a transaction proof of publication
chain.

Each transaction would be added to that chain when it is received.  It
could be merge mined with the main chain.

If the size was limited, then it doesn't even require spam protection.

Blocks could be discouraged if they have transactions which violate the
ordering in that chain.  Miners could still decide which transactions they
include, but couldn't include transactions which are double spends.

The locktime/final field could be used for transactions which want to be
replaceable.

The chain could use some of the fast block proposals.  For example, it
could include orphans of a block when computing the block's POW.



On Wed, Apr 23, 2014 at 9:53 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter 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.

 Large scale consensus can't generally provide instantly irreversible
 transactions directly: Increasing the block speed can't help past the
 point where the time starts getting close to the network diameter...
 you simply can't tell what a consensus of a group of nodes is until
 several times the light cone that includes all of them.  And if you
 start getting close to the limit you dilute the power working on the
 consensus and potentially make life easier for a large attacker.

 Maybe other chains with different parameters could achieve a different
 tradeoff which was better suited to low value retail transactions
 (e.g. where you want a soft confirmation fast). A choice of tradeoffs
 could be very useful, and maybe you can practically get close enough
 (e.g. would knowing you lost a zero-conf double spend within 30
 seconds 90% of the time be good enough?)... but I'm not aware of any
 silver bullet there which gives you something identical to what a
 centralized service can give you without invoking at least a little
 bit of centralization.


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

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 11:18 PM, Luke-Jr wrote:
 Only a very niche user base needs funds isolated...

Our users do and we are creating this BIP for them, because we love them. ;)

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

--
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-23 Thread Pavol Rusnak
On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
 Hopefully it would be clarified as only a MUST NOT do so silently...
 I have funds split across two wallets and it WONT LET ME SPEND THEM
 sounds like a terrible user experience. :)

That is a subjective matter. To me it makes PERFECT SENSE that funds
across accounts NEVER MIX. One can still send funds from one account to
another and then perform another spend.

That's what I consider a consistent and thus GOOD user experience.
What's the purpose of Accounts if wallet mixes coins among them anyway?

I know it's not good to use classic bank accounts as analogy, but that's
exactly how they work. Or have you every done ONE transaction from two
bank accounts simultaneously?

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

--
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 Gregory Maxwell
On Wed, Apr 23, 2014 at 2:23 PM, Tier Nolan tier.no...@gmail.com wrote:
 An interesting experiment would be a transaction proof of publication
 chain.

 Each transaction would be added to that chain when it is received.  It could
 be merge mined with the main chain.

 If the size was limited, then it doesn't even require spam protection.

 Blocks could be discouraged if they have transactions which violate the
 ordering in that chain.  Miners could still decide which transactions they
 include, but couldn't include transactions which are double spends.

 The locktime/final field could be used for transactions which want to be
 replaceable.

 The chain could use some of the fast block proposals.  For example, it could
 include orphans of a block when computing the block's POW.

You can see me proposing this kind of thing in a number of places (e.g.
http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt p2pool
only forces the subsidy today, but the same mechnism could instead
force transactions.. e.g. to get you fast confirmation., or
previously on BCT for the last couple years) but there are still
limits here:  If you don't follow the fast-confirmation share chain
you cannot mine third party transactions because you'll be at risk of
mining a double spend that gets you orphaned, or building on a prior
block that other miners have decided is bad.  This means that if the
latency or data rate requirements of the share chain are too large
relative to ordinary mining it may create some centralization
pressure.

That said, I think using a fast confirmation share-chain is much
better than decreasing block times and could be a very useful tool if
we believe that there are many applications which could be improved
with e.g. a 30 second or 1 minute interblock time.  Mostly my thinking
has been that these retail applications really want sub-second
confirmation, which can't reasonably be provided in this manner so I
didn't mention it in this thread.

One of the neat things about this is that you can introduce it totally
separately from Bitcoin without any consensus or approval from anyone
else— E.g. P2pool builds such a chain today though it doesn't enforce
transactions.  It would immediately provide the useful service of
demonstrating that some chunk of hashpower was currently working on
including a particular set of transactions.  Once the details were
worked out it could be added as a soft-forking requirement to the
commonly run system.

--
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-23 Thread Pieter Wuille
On Wed, Apr 23, 2014 at 11:33 PM, Pavol Rusnak st...@gk2.sk wrote:
 On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
 Hopefully it would be clarified as only a MUST NOT do so silently...
 I have funds split across two wallets and it WONT LET ME SPEND THEM
 sounds like a terrible user experience. :)

 That is a subjective matter. To me it makes PERFECT SENSE that funds
 across accounts NEVER MIX. One can still send funds from one account to
 another and then perform another spend.

In that case, maybe it makes sense to define another purpose id
without accounts as well already.

I believe many simple wallets will find multiple subwallets too
burdening for the user experience, or not worth the technical
complexity.

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


Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 11:42 PM, Pieter Wuille wrote:
 In that case, maybe it makes sense to define another purpose id
 without accounts as well already.
 
 I believe many simple wallets will find multiple subwallets too
 burdening for the user experience, or not worth the technical
 complexity.

Right. See my previous email where I describe hypothetical creation of
BIP65 and BIP66 which the exact thing you describe.

-- 
Best Regards / S pozdravom,

Pavol Rusnak st...@gk2.sk

--
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-23 Thread Gregory Maxwell
On Wed, Apr 23, 2014 at 2:42 PM, Pieter Wuille pieter.wui...@gmail.com wrote:
 In that case, maybe it makes sense to define another purpose id
 without accounts as well already.

 I believe many simple wallets will find multiple subwallets too
 burdening for the user experience, or not worth the technical
 complexity.

Or implement them but in a form where the different wallets can have
different security policies and thus wouldn't share a common piece of
private key material.  I can see it being pretty confusing to have
multiple wallets which are both sharing a private key and not sharing
a private key.

--
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-23 Thread Luke-Jr
On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote:
 On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
  Hopefully it would be clarified as only a MUST NOT do so silently...
  I have funds split across two wallets and it WONT LET ME SPEND THEM
  sounds like a terrible user experience. :)
 
 That is a subjective matter. To me it makes PERFECT SENSE that funds
 across accounts NEVER MIX. One can still send funds from one account to
 another and then perform another spend.

Only by crossing the blockchain unnecessarily.

 That's what I consider a consistent and thus GOOD user experience.
 What's the purpose of Accounts if wallet mixes coins among them anyway?

To keep balances separated. For example, I might have an account for each of 
my children, move their allowance money to it every day/week (off-chain), and 
they can spend only what they have in their account. Or an exchange might have 
an account for each user's deposits. In neither case, would it make sense to 
pay special attention to which UTXOs are consumed in transactions from any of 
the account.

The only use case that requires tracking UTXOs per-account is when you want to 
have multiple uncoordinated copies of the wallet in use at the same time, and 
therefore need to immediately identify which account a transaction came from 
based on the UTXOs it consumed - although even then, you could still mix funds 
as long as you use only the first UTXO for tracking, so maybe there isn't even 
a niche use case! In any case, Trezor, being a hardware wallet, should never 
overlap with this niche...?

 I know it's not good to use classic bank accounts as analogy, but that's
 exactly how they work. Or have you every done ONE transaction from two
 bank accounts simultaneously?

Bad analogy. Banks *always* mix funds. You don't expect your bank wire to use 
exactly the specific dollar bills you deposited, do you??

Luke

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

 These sorts of proposals are all just ways of saying block chains kind of
 suck and we should go back to using trusted third parties.


No.
Different approaches have different trade-offs, and thus different areas of
applicability.

Proof-of-work's inherent disadvantage is that it takes some time until
transaction becomes practically irreversible. On the other hand, it has
advantages like neutrality, censorship-resistance, high degree of security,
etc.

TTP can be very efficient, but doesn't have advantages mentioned above.

It is possible to combine several different approaches into one hybrid
systems. For example, classic Bitcoin PoW blockchain can be used for
settlements, large transactions, savings and so on. While TTP-based payment
system will be used for small-value transaction like buying coffee.

In this case you get benefits of both approaches. Censorship-resistance is
irrelevant when one buys a cup of coffee with his pocket money, isn't it?

For some reason, instead of considering these hybrid solutions (which can
also address scalability problems), you want to make PoW-based system more
complex to be applicable for real-time transaction too.

This will, likely, weaken advantages provided by PoW, and also it won't
provide any hard guarantees, and, if implemented, will undermine
development of alternative solutions.
--
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 Tier Nolan
On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.comwrote:

 You can see me proposing this kind of thing in a number of places (e.g.
 http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt p2pool
 only forces the subsidy today, but the same mechnism could instead
 force transactions..


Interesting.  You set the share-block size to 16kB and set the share POW to
1/64 of the main target.

Each share-block would be allowed to append up to 16kB on the previous
share-block.

This would keep the bandwidth the same, but on average blocks would be only
512kB.

e.g. to get you fast confirmation., or
 previously on BCT for the last couple years) but there are still
 limits here:  If you don't follow the fast-confirmation share chain
 you cannot mine third party transactions because you'll be at risk of
 mining a double spend that gets you orphaned, or building on a prior
 block that other miners have decided is bad.  This means that if the
 latency or data rate requirements of the share chain are too large
 relative to ordinary mining it may create some centralization
 pressure.


This effect could be reduced by having colours for blocks and
transactions.

The block colour would be a loop based on block height.

You could have 16 transaction colours based on the lowest 4 bits in the
txId.

A transaction is only valid if all inputs into the transaction are the
correct colour for that block.

This allows blocks to be created in advance.  If you are processing colour
7 at the moment, you can have a colour 8 block ready.

16 colours is probably to many.   It would only be necessary for things
like 1 second block rates.

The disadvantage is that wallets would have to make sure that they have
coins for each of the 16 colours.

If you spend the wrong colour, you add 16 block times of latency.



 That said, I think using a fast confirmation share-chain is much
 better than decreasing block times and could be a very useful tool if
 we believe that there are many applications which could be improved
 with e.g. a 30 second or 1 minute interblock time.  Mostly my thinking
 has been that these retail applications really want sub-second
 confirmation, which can't reasonably be provided in this manner so I
 didn't mention it in this thread.


In a shop setting, you could set it up so that the person scans a QR-code
to setup a channel with the shop.

They can then scan all their stuff and by the time they have done that, the
channel would be ready.

If there was a queue, it could be done when the person enters the queue.

In fact, there could be QR-codes at multiple locations.
--
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

2014-04-23 Thread Gregory Maxwell
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.

I agree that we shouldn't be statically linking QT on linux generally
(due to things like theming), though maybe we could just have the
build process dump out a seperate extra static QT binary just for
these other cases? I feel like the work maintaining it would be less
than what we've had in answering questions/complaints about 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] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-23 Thread Tom Harding
On 4/22/2014 9:03 PM, Matt Whitlock wrote:
 On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote:
 A network where transaction submitters consider their (final)
 transactions to be unchangeable the moment they are transmitted, and
 where the network's goal is to confirm only transactions all of whose
 UTXO's have not yet been seen in a final transaction's input, has a
 chance to be such a network.
 Respectfully, this is not the goal of miners. The goal of miners is to 
 maximize profits. Always will be. If they can do that by enabling 
 replace-by-fee (and they can), then they will. Altruism does not factor into 
 business.

The rational miner works hard digging hashes out of the ether, and wants 
the reward to be great.  How much more valuable would his reward be if 
he were paid in something that is spendable like cash on a 1-minute 
network for coffee and other innumerable real-time transactions, versus 
something that is only spendable on a 15-minute network?

There is a prisoner's dilemma, to be sure, but do the fees from helping 
people successfully double-spend their coffee supplier really outweigh 
the increased value to the entire network - including himself - of 
ensuring that digital cash actually works like cash?



--
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] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-23 Thread Simon Barber
Miners earn bitcoins, and clearly a network where reasonable certainty 
can be achieved with 0-confirm transactions is more useful, thus will 
result in those bitcoins being more valuable. One would expect rational 
miners (or pool operators) to want to collaborate to reduce the 
possibilities for double spend attacks as much as possible.

Simon

On 4/23/2014 3:29 PM, Tom Harding wrote:
 On 4/22/2014 9:03 PM, Matt Whitlock wrote:
 On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote:
 A network where transaction submitters consider their (final)
 transactions to be unchangeable the moment they are transmitted, and
 where the network's goal is to confirm only transactions all of whose
 UTXO's have not yet been seen in a final transaction's input, has a
 chance to be such a network.
 Respectfully, this is not the goal of miners. The goal of miners is to 
 maximize profits. Always will be. If they can do that by enabling 
 replace-by-fee (and they can), then they will. Altruism does not factor into 
 business.
 The rational miner works hard digging hashes out of the ether, and wants
 the reward to be great.  How much more valuable would his reward be if
 he were paid in something that is spendable like cash on a 1-minute
 network for coffee and other innumerable real-time transactions, versus
 something that is only spendable on a 15-minute network?

 There is a prisoner's dilemma, to be sure, but do the fees from helping
 people successfully double-spend their coffee supplier really outweigh
 the increased value to the entire network - including himself - of
 ensuring that digital cash actually works like cash?



 --
 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] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Tom Harding

On 4/23/2014 2:23 PM, Tier Nolan wrote:
 An interesting experiment would be a transaction proof of 
 publication chain.

What if a transaction could simply point back to an earlier transaction, 
forming a chain?  Not a separately mined blockchain, just a way to 
establish an official publication (execution) order. Double spends would 
be immediately actionable with such a sequence. Transactions in a block 
could eventually be required to be connected in such a chain.  Miners 
would have to keep or reject a whole mempool chain, since they lack the 
keys to change the sequence.  They would have to prune a whole tx 
subchain to insert a double spend (and this would still require private 
keys to the double spend utxo's).

This idea seemed promising, until I realized that with the collision 
rebasing required, it would barely scale to today's transaction rate.  
Something that scales to 10,000's of transactions per second, and really 
without limit, is needed.

Anyway, I wrote it up here: 
https://github.com/dgenr8/out-there/blob/master/tx-chains.md


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

2014-04-23 Thread Kristov Atlas

On 04/23/2014 06:28 PM, Gregory Maxwell wrote:
 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.

 I agree that we shouldn't be statically linking QT on linux generally
 (due to things like theming), though maybe we could just have the
 build process dump out a seperate extra static QT binary just for
 these other cases? I feel like the work maintaining it would be less
 than what we've had in answering questions/complaints about it.

 --
Dumping out a separate, extra static QT binary is a great idea.

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