[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 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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
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
-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
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
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
-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
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
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
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
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
-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
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
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
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
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
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
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
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
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
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]
(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
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
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
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] New BIP32 structure
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
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
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
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
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] New BIP32 structure
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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] Coinbase reallocation to discourage Finney attacks
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
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
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
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
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
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
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
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
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
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
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
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] Coinbase reallocation to discourage Finney attacks
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
