[Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Mike Hearn
Lately someone launched Finney attacks as a service (BitUndo). As a reminder for newcomers, Finney attacks are where a miner secretly works on a block containing a double spend. When they eventually find a block, they run to the merchant and pay, then broadcast the block. In a simpler variant of

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

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

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

2014-04-23 Thread Tamas Blummer
The problem is µBTC that bit tries to solve. BTC, mBTC and µBTC are just too similiar for enyone else than engineers. The mixed use of them leads to misunderstanding. I think adoption would benefit of a single unit with easily remembered and associated name that has no smaller than 1/100

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

2014-04-23 Thread Andy Parkins
On Wednesday 23 Apr 2014 08:55:30 Mike Hearn wrote: Even with their woeful security many merchants see 1-2% credit card chargeback rates, and chargebacks can be disputed. In fact merchants win about 40% of chargeback disputes. So if N was only, say, 5%, and there was a large enough population

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

2014-04-23 Thread Chris D'Costa
I have a rather off-beat suggestion. Perhaps decimal was not satoshi's intention. In old English money 1 guinea is 21 shillings. I wonder if 1 million guineas is more or less the total number of bitcoins = 21 million shillings. There was also the notion of bits (two bob bits = 1 florin = 2

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

2014-04-23 Thread Christophe Biocca
Just a few issues with the idea as it currently stands: 1. This provides a very strong incentive to always vote for reallocating a block if it isn't yours, regardless of whether it's bad or not (there's a positive expected return to voting to reallocate coinbases from other miners). The incentive

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

2014-04-23 Thread Andy Parkins
On Wednesday 23 Apr 2014 12:45:34 Mike Hearn wrote: OK, sure, let's say most Bitcoin users will be honest (we hope). But unfortunately in a situation where fraud is possible users wouldn't necessarily distribute evenly over transactions. That's true, but even in the worst that that 5% hashing

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

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 07:55 AM, Mike Hearn wrote: 2. Miners can vote to reallocate the coinbase value of bad blocks before they mature. If a majority of blocks leading up to maturity vote for reallocation, the value goes into a pot that subsequent blocks

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

2014-04-23 Thread Alex Mizrahi
This is outright ridiculous. Zero-confirmation double-spending is a small problem, and possible solutions are known. (E.g. trusted third party + multi-sig addresses for small-value transactions.) On the other hand, protocol changes like described above might have game-theoretical implications

Re: [Bitcoin-development] Economics of information propagation

2014-04-23 Thread Peter Todd
On Mon, Apr 21, 2014 at 01:30:28AM +, Jonathan Levin wrote: CC'ing bitcoin-research - may be more appropriate to move the discussion there as this discussion is delving into future scenarios. Hi all, I am a post-graduate economist writing a paper on the incentives of mining. Even

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

2014-04-23 Thread Alex Mizrahi
And it still would. Non-collusive miners cast votes based on the outcome of their own attempts to double spend. Individually rational strategy is to vote for coinbase reallocation on every block. Yes, in that case nobody will get reward. It is similar to prisoner's dilemma: equilibrium has

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

2014-04-23 Thread Pieter Wuille
On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote: I have some questions: 1. How can we work towards solving the double-spending problem? We have this awesome technology that solves the double-spending problem. It's called a blockchain. Of course, it only works when

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

2014-04-23 Thread Peter Todd
On Wed, Apr 23, 2014 at 05:41:26PM +0200, Pieter Wuille wrote: On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote: I have some questions: 1. How can we work towards solving the double-spending problem? We have this awesome technology that solves the double-spending

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

2014-04-23 Thread Christophe Biocca
It's not necessary that this coinbase retribution be either profitable or risk-free for this scheme to work. I think we should separate out the different layers of the proposal: 1. Attacking the coinbase instead of orphaning allows for 100 blocks' time for a consensus to be reached, rather than

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

2014-04-23 Thread Chris Pacia
What is the advantage of this proposal over just orphaning the block with double spends? There's currently a set of rules which government what constitutes a valid block. Miners don't build on blocks that don't accord with those rules out of fear that a major won't follow and they will waste

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

2014-04-23 Thread Kevin
On 4/23/2014 12:04 PM, Christophe Biocca wrote: It's not necessary that this coinbase retribution be either profitable or risk-free for this scheme to work. I think we should separate out the different layers of the proposal: 1. Attacking the coinbase instead of orphaning allows for 100

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

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 03:07 PM, Mike Hearn wrote: On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier justusranv...@gmail.comwrote: If enough miners don't like a block that has been mined, they can all work to orphan it without any change to the protocol

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pieter Wuille
On Tue, Apr 8, 2014 at 5:41 PM, slush sl...@centrum.cz wrote: I've discussed the solution of Litecoin seed in BIP32 HMAC with Litecoin devs already, and after long discussion we've concluded that it is generally bad idea. When changing Bitcoin seed constant to something different, same

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

2014-04-23 Thread Gavin Andresen
I've formulated my replies to you and this proposal in a more public venue, where such discussions of existential changes to the protocol more rightfully belong I strongly disagree. It makes perfect sense to discuss changes here, first, where there are lots of people who understand how the

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

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 05:47 PM, Gavin Andresen wrote: And why do you think your blog is more public than this open, publicly archived mailing list??? Non-developers are more comfortable using social media tools. Blog posts can be shared, Tweeted, and

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

2014-04-23 Thread Mike Hearn
Non-developers are more comfortable using social media tools. Blog posts can be shared, Tweeted, and commented upon using nothing more than a web browser. I don't think Twitter is an appropriate medium for discussing the details of byzantine consensus algorithms. I'm not going to bother

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread slush
On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille pieter.wui...@gmail.comwrote: Storing the seed is superior to storing the master node already (whether coin specific or not), as it is smaller. ...Except that you're loosing flexibility (serialization, deserialization) which gives you BIP32 node.

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 08:39 PM, Tier Nolan wrote: A merchant could easily send 20 addresses in a row to customers and none of them bother to actually buy anything. Such merchant would surely use some merchant system instead of generic wallet software. Setting the gap limit to high is just a small

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
The most useful meta data to optimize chain scan is the key birth date, then the allowed gap size. Tamas Blummer http://bitsofproof.com On 23.04.2014, at 20:39, Tier Nolan tier.no...@gmail.com wrote: Different users could have different gap limit requirements. 20 seems very low as the

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

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 06:37 PM, Mike Hearn wrote: If you want to try and argue that the development list is the wrong place to discuss development, please do so on another thread (or your blog). Let's keep this thread for discussion of the original

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

2014-04-23 Thread Gregory Maxwell
On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn m...@plan99.net wrote: Lately someone launched Finney attacks as a service (BitUndo). As a reminder for newcomers, Finney attacks are where a miner secretly works on a block containing a double spend. Hm? I didn't think this is at all what they did.

Re: [Bitcoin-development] New BIP32 structure

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

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

2014-04-23 Thread Drak
Cut it out with the ad hominem attacks please. If you cant be civil, please go away until you learn some manners. I think the issue being discussed is do you orphan an entire block causing distress to users as well, or try to just cause distress just to the evil miner? This discussion is about

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
I built such a merchant system handing out BIP32 addresses. The gap size problem does not arise there since such a system has to have an extra database keeping track of requests, so there is no added cost of storing the key coordinates used by them. A scan is not needed the keys can be

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread slush
Using higher gap limit in the software is not prohibited, but then it breaks the standard as is, in mean that importing such wallet to another BIP64 wallet won't recover the funds properly, without proper settings of gap limit... Gap limit 20 is the most sane defaults for majority of users

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

2014-04-23 Thread Mike Hearn
On Wed, Apr 23, 2014 at 8:57 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Hm? I didn't think this is at all what they did. What they claim to do is to prioritize transactions in their mempool from people who pay them That's the definition of a Finney attack, right? A tx is broadcast and

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 09:00 PM, Tier Nolan wrote: The point is to have a single system that is compatible over a large number of systems. There is such system and it is called BIP32. On the other hand, in BIP64 we try to put a set of restrictions and rules on top of BIP32. There will always be some

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
Pieter suggested in IRC couple of months ago to append key birth to key serialization in xprv….@unixtime format. What about picking this idea up in BIP64? It would greatly help the importing client. Regards, Tamas Blummer http://bitsofproof.com signature.asc Description: Message signed

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote: On 04/23/2014 09:00 PM, Tier Nolan wrote: The point is to have a single system that is compatible over a large number of systems. There is such system and it is called BIP32. On the other hand, in BIP64 we try to put a set of

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

2014-04-23 Thread Sergio Lerner
(this e-mail is cc to the bitcoin-research list) Hi everyone from the bitcoin-development mailing list! I decided to join this legendary list because it seems that all the research fun is taking place in here, and I don't want to miss the research party. Regarding the discussion about BitUndo, a

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 09:44 PM, Luke-Jr wrote: Why do clients need to use the features in BIP 64? If Electrum doesn't want to use accounts, then it can just use account 0 for everything. Refund chains are As Andreas wrote earlier in this thread: There is no bare minimum. Either you implement the

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread slush
On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs are in the wallet, they are no longer associated with the address

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

2014-04-23 Thread Mike Hearn
What you're talking about is just disagreement about the content of the memory pool That's the same thing. Whilst you're mining your double spend tx, it's in your mempool but you don't broadcast it as per normal. Then when you find the block you broadcast it to override everyone elses

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:57:46 PM slush wrote: On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs are in

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote: On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs are in the

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
On 23.04.2014, at 22:02, Luke-Jr l...@dashjr.org wrote: On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote: On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses

Re: [Bitcoin-development] New BIP32 structure

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

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

2014-04-23 Thread Kristov Atlas
On 04/22/2014 09:30 AM, Warren Togami Jr. wrote: Bitcoin-Translators mailing list is an announce-only mailing list for developers to communicate to translators at particular times when new translations are needed. Replies and discussion would go to the bitcoin dev list. Subscriptions to this

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pieter Wuille
That's the point. BIP64 specifies such a structure, and you have to scan all that it defines. If you want to write wallet software that does not have the complexity to deal with just one account, it is not BIP64 compliant. It could try to define its own purpose system, with a hierarchy without

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pieter Wuille
I believe Luke means scanning chains as defined by the structure, but not handing out addresses from other accounts than the first one. That's certainly a possibly way to compatibly implement BIP64, but it doesn't reduce all that much complexity. I hope people would choose that over defining

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Tamas Blummer
On 23.04.2014, at 22:09, Luke-Jr l...@dashjr.org wrote: On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote: On 04/23/2014 10:01 PM, Luke-Jr wrote: Yes, it should scan all possible (under the BIP-defined structure) branches regardless of which features it supports. So you suggest to

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 10:09 PM, Luke-Jr wrote: Scan all branches for UTXOs, then you have the balance for the wallet. Account balances are metadata, so cannot be known from the seed alone. If you want to have a way to restore accounts, you must define some more detailed wallet file format

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

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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:16:45 PM Pavol Rusnak wrote: On 04/23/2014 10:09 PM, Luke-Jr wrote: Scan all branches for UTXOs, then you have the balance for the wallet. Account balances are metadata, so cannot be known from the seed alone. If you want to have a way to restore accounts, you

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 10:32 PM, Luke-Jr wrote: f) I missed the part where BIP 32 redefined account to mean subwallet instead of what has traditionally been called account in Bitcoin. Ah, okay. The last time I saw Bitcoin-qt it was still using independent addresses. In that case, single-subwallet

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

2014-04-23 Thread Mike Hearn
On Wed, Apr 23, 2014 at 10:24 PM, Gregory Maxwell gmaxw...@gmail.comwrote: Right, this works in the Bitcoin network today absent any collusion by the miners. You give one miner a transaction and you give every other node you can reach another transaction. Yes, but that can be fixed with

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

2014-04-23 Thread Warren Togami Jr.
On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas kristovat...@gmail.comwrote: I see that the latest nightly build (thanks for that, Warren) is still not compatible with Tails/Debian Squeeze. Is there still an intention to address this issue? Might it be fixed by 0.9.2? If I understand the

Re: [Bitcoin-development] New BIP32 structure

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

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

2014-04-23 Thread Adam Ritter
Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation transactions, the Bitcoin blockchain wouldn't even be needed. On Wed, Apr 23, 2014 at 10:37 PM, Mike Hearn m...@plan99.net wrote: On Wed, Apr 23, 2014 at 10:24

Re: [Bitcoin-development] New BIP32 structure

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

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

2014-04-23 Thread Kristov Atlas
On 04/23/2014 04:39 PM, Warren Togami Jr. wrote: On Wed, Apr 23, 2014 at 10:05 AM, Kristov Atlas kristovat...@gmail.com mailto:kristovat...@gmail.com wrote: I see that the latest nightly build (thanks for that, Warren) is still not compatible with Tails/Debian Squeeze. Is there still

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

2014-04-23 Thread Gregory Maxwell
On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter arit...@gmail.com wrote: Isn't a faster blockchain for transactions (maybe as a sidechain) solving the problem? If there would be a safe way for 0-confirmation transactions, the Bitcoin blockchain wouldn't even be needed. Large scale consensus can't

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread slush
On Wed, Apr 23, 2014 at 10:54 PM, Pieter Wuille pieter.wui...@gmail.comwrote: Would you consider software which scans all accounts as specified by BIP64, but has no user interface option to distinguish them in any way, view them independently, and has no ability to keep the coins apart...

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

2014-04-23 Thread Daniel Krawisz
The memory pool is just talk. There is no expectation that the memory pool has to satisfy some standard as to what will eventually exist in the block chain, and there are any number of ways that people could communicate transactions to one another without putting them in the memory pool. The

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 9:06:26 PM Pavol Rusnak wrote: On 04/23/2014 10:54 PM, Pieter Wuille wrote: 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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Gregory Maxwell
On Wed, Apr 23, 2014 at 2:18 PM, Luke-Jr l...@dashjr.org wrote: How do you get the more expected/usual behaviour of mixing funds between accounts? Only a very niche user base needs funds isolated... Hopefully it would be clarified as only a MUST NOT do so silently... I have funds split across

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

2014-04-23 Thread Tier Nolan
An interesting experiment would be a transaction proof of publication chain. Each transaction would be added to that chain when it is received. It could be merge mined with the main chain. If the size was limited, then it doesn't even require spam protection. Blocks could be discouraged if

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 11:18 PM, Luke-Jr wrote: Only a very niche user base needs funds isolated... Our users do and we are creating this BIP for them, because we love them. ;) -- Best Regards / S pozdravom, Pavol Rusnak st...@gk2.sk

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pavol Rusnak
On 04/23/2014 11:22 PM, Gregory Maxwell wrote: Hopefully it would be clarified as only a MUST NOT do so silently... I have funds split across two wallets and it WONT LET ME SPEND THEM sounds like a terrible user experience. :) That is a subjective matter. To me it makes PERFECT SENSE that

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

2014-04-23 Thread Gregory Maxwell
On Wed, Apr 23, 2014 at 2:23 PM, Tier Nolan tier.no...@gmail.com wrote: An interesting experiment would be a transaction proof of publication chain. Each transaction would be added to that chain when it is received. It could be merge mined with the main chain. If the size was limited, then

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Gregory Maxwell
On Wed, Apr 23, 2014 at 2:42 PM, Pieter Wuille pieter.wui...@gmail.com wrote: In that case, maybe it makes sense to define another purpose id without accounts as well already. I believe many simple wallets will find multiple subwallets too burdening for the user experience, or not worth the

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote: On 04/23/2014 11:22 PM, Gregory Maxwell wrote: Hopefully it would be clarified as only a MUST NOT do so silently... I have funds split across two wallets and it WONT LET ME SPEND THEM sounds like a terrible user experience. :)

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

2014-04-23 Thread Alex Mizrahi
These sorts of proposals are all just ways of saying block chains kind of suck and we should go back to using trusted third parties. No. Different approaches have different trade-offs, and thus different areas of applicability. Proof-of-work's inherent disadvantage is that it takes some time

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

2014-04-23 Thread Tier Nolan
On Wed, Apr 23, 2014 at 10:39 PM, Gregory Maxwell gmaxw...@gmail.comwrote: You can see me proposing this kind of thing in a number of places (e.g. http://download.wpsoftware.net/bitcoin/wizards/2014-04-15.txt p2pool only forces the subsidy today, but the same mechnism could instead force

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

2014-04-23 Thread Gregory Maxwell
On Wed, Apr 23, 2014 at 1:39 PM, Warren Togami Jr. wtog...@gmail.com wrote: If you are a rare user who needs Bitcoin-Qt on an incompatible system you can at least build it from source. Tails users usually can't really build it from source— talks is a live boot mostly stateless linux

Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-23 Thread Tom Harding
On 4/22/2014 9:03 PM, Matt Whitlock wrote: On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote: A network where transaction submitters consider their (final) transactions to be unchangeable the moment they are transmitted, and where the network's goal is to confirm only transactions all

Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

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

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

2014-04-23 Thread Tom Harding
On 4/23/2014 2:23 PM, Tier Nolan wrote: An interesting experiment would be a transaction proof of publication chain. What if a transaction could simply point back to an earlier transaction, forming a chain? Not a separately mined blockchain, just a way to establish an official publication

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

2014-04-23 Thread Kristov Atlas
On 04/23/2014 06:28 PM, Gregory Maxwell wrote: Tails users usually can't really build it from source— talks is a live boot mostly stateless linux distribution for privacy applications. It's really good in general. I agree that we shouldn't be statically linking QT on linux generally (due to