Re: [Bitcoin-development] Compatibility Bitcoin-Qt with Tails
On Sat, Apr 26, 2014 at 7:29 PM, Kristov Atlas aut...@anonymousbitcoinbook.com wrote: Hey Wladimir, Thanks for building this binary. The initial problem with Qt was resolved, and I was able to load the GUI that chooses my datadir. After choosing the default datadir, however, it segfaulted. I've fixed the issue; at least on Debian 6 - which is a lot more conductive to development than tails :-). See https://github.com/bitcoin/bitcoin/pull/4094 for the gory details. New test build available: https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz (sigs: https://download.visucore.com/bitcoin/linux-gitian-3cbabfa.tar.gz.sig ) Wladimir -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 30/04/14 00:26, Mike Hearn wrote: These parties wouldn't generally consider themselves attackers Of course not, attackers rarely do :) If Bitcoin works correctly nobody should have to care if they consider themselves attackers, defenders, or little green men from Mars. There are simply nodes that follow the protocol, and nodes that do not. The fact that you even need to think about who should and should not be considered an attacker, in the context of your proposed change, should be ringing alarm bells :) What do you think miners exist for? Ordering transactions. signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 30/04/14 00:13, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I haven't seen anybody arguing that it is. Bitcoin is the elegant embodiment of /artificially contrived/ mathematical rules, which just so happen to be very useful in their current configuration :-P Nobody is saying those rules are immutable. Just that it isn't sensible to undermine them by introducing imprecise and unpredictable elements like human politics. Every time miners and nodes ignore a block that creates formula() coins that's a majority vote on a controversial political matter No it isn't. That's the node enforcing the protocol. It isn't a matter of opinion, and it isn't a vote. The protocol is clearly defined: you either follow it or you're not running a Bitcoin node. If 51% don't follow it tomorrow /they're/ not running Bitcoin. Contrast with your vote to reinterpret the meaning of arbitrary blocks mechaism - you're free to vote either way while remaining within the protocol. That's a /real/ vote - majority decides what the Bitcoin protocol /and every node that follows it/ will recognise as valid. Nothing like that currently exists. Thank $deity. signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
I think we're going around in circles here so this will be my last message on the thread unless someone comes up with something new. On Wed, Apr 30, 2014 at 3:12 PM, Gareth Williams gac...@gmail.com wrote: If Bitcoin works correctly nobody should have to care if they consider themselves attackers, defenders, or little green men from Mars. One last time, I request that people read the white paper from 2008 before making statements like this. If the notion of attacker was irrelevant to Bitcoin, it would not be mentioned in the abstract, would it? -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 30/04/14 00:13, Mike Hearn wrote: Every time miners and nodes ignore a block that creates formula() coins that's a majority vote on a controversial political matter Actually, there's one more thing I'd like to add. Apologies to the list, but it bears repeating: * rejecting a block at validation Is /very different/ from: * reinterpreting a block that has already passed validation Nodes ignoring a block that creates formula() coins is rejection at block *validation*. That's the protocol working as it is supposed to. It's deliberately an all-or-nothing mechanism; you can't pick and choose which blocks you like. If 51% of the network say your block is invalid, they're now on a different fork. The consequences are this drastic on purpose, for stability. Nodes reinterpreting a block that has already passed validation is almost the polar opposite of this. They're /ignoring the protocol/ and making up their own meaning for stuff. Sidestepping the mechanism in the paragraph above. I would hope it'd be self evident that this is dangerous. Adam Back is arguing practicality in this thread. I'm arguing fundamental principle. (And, er, someone else is randomly throwing around ad hominems, which we'll politely ignore; Mike could work for Lucifer himself and his good ideas would still be good, and his bad ideas would still be bad, so let's just stick to the ideas eh.) So, fundamental principle: don't reinterpret history! We have validation for a very good reason. Undermine it and you might as well have an unvalidated system like Counterparty, which I wouldn't ever trust with more than the value of a small hamburger. If the economic majority starts reinterpreting history (through whatever voting mechanism / side-channel you like) that completely undermines Bitcoin's validation, and its PoW. It's worse than 51% of miners deciding to rewrite history. signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 30/04/14 23:55, Mike Hearn wrote: If Bitcoin works correctly nobody should have to care if they consider themselves attackers, defenders, or little green men from Mars. One last time, I request that people read the white paper from 2008 before making statements like this. If the notion of attacker was irrelevant to Bitcoin, it would not be mentioned in the abstract, would it? I've read it :) The notion of an attacker is obviously relevant to someone designing the system. It should not be relevant to someone running a node. I'll retire from posting on this too, I've posted way too much. Our fundamental disagreement is simply that you think Bitcoin is, or should be, a /democratic/ system. I think Bitcoin is, and should be, a /trustless/ system. If we're going to resort to appeal to authority, I'll point to the words Electronic Cash System in the title of Satoshi's whitepaper :-P He intended to create ecash; that's widely understood to mean trustless. If there was this magic computer up in the sky somewhere, free from human influence, that would run Satoshi's code for him in perpetuity (let's overlook the initial upload please, bear with me), then I believe Satoshi would've built his perfectly trustless ecash to run on that. For lack of such a magic masterless computer he had to approximate one, ingeniously using distributed consensus to achieve it. That's his real invention - the magic masterless computer simulator, and the incentive scheme to get the world to run it for him. (We'll see more of what it can do if Ethereum ever gets off the ground.) But for Pete's sake, Bitcoin is trustless. Just because the infrastructure it sits atop is democratic (because there was no other way to implement it,) doesn't mean you suddenly have to start voting on everything. signature.asc Description: OpenPGP digital signature -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote: On 30/04/14 00:13, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I haven't seen anybody arguing that it is. Bitcoin is the elegant embodiment of /artificially contrived/ mathematical rules, which just so happen to be very useful in their current configuration :-P Nobody is saying those rules are immutable. Just that it isn't sensible to undermine them by introducing imprecise and unpredictable elements like human politics. As an end-user of Bitcoin, the whole possible value of a set of mathematical rules has become completely trashed by the imprecise and unpredictable behavior of buyers and sellers. If the rules are not responsive to real human needs, bitcoin is worthless as a long-term store of value because **my idea of value** changes over time. This implies, in my mind, an absolutely requirement to attempt to gather some useful signal from the human political noise. How do you determine what that signal is, so you can **change the rules** and the mathematics so it makes more sense? You've got to deal with politics, one way or another. -- Troy Benjegerdes 'da hozer' ho...@hozed.org 7 elements earth::water::air::fire::mind::spirit::soulgrid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
Perhaps I missed it somewhere, but I don't recall it ever being a goal of Bitcoin to act as a stable long-term store of value. - Jameson On 04/30/2014 01:06 PM, Troy Benjegerdes wrote: On Wed, Apr 30, 2014 at 11:00:06PM +1000, Gareth Williams wrote: On 30/04/14 00:13, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I haven't seen anybody arguing that it is. Bitcoin is the elegant embodiment of /artificially contrived/ mathematical rules, which just so happen to be very useful in their current configuration :-P Nobody is saying those rules are immutable. Just that it isn't sensible to undermine them by introducing imprecise and unpredictable elements like human politics. As an end-user of Bitcoin, the whole possible value of a set of mathematical rules has become completely trashed by the imprecise and unpredictable behavior of buyers and sellers. If the rules are not responsive to real human needs, bitcoin is worthless as a long-term store of value because **my idea of value** changes over time. This implies, in my mind, an absolutely requirement to attempt to gather some useful signal from the human political noise. How do you determine what that signal is, so you can **change the rules** and the mathematics so it makes more sense? You've got to deal with politics, one way or another. -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol
Due to popular demand, I have created a BIP for cross chain atomic transfers. Unlike the previous version, this version only requires hash locking. The previous version required a selector transaction based on if statements. OP_HASH160 OP_EQUAL_VERIFY [public key] OP_CHECKSIG OP_HASH160 OP_EQUAL_VERIFY OP_N [public key 1] ... [public key m] OP_M OP_CHECK_MULTISIG https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol
On Wednesday, April 30, 2014 6:03:59 PM Tier Nolan wrote: Due to popular demand, I have created a BIP for cross chain atomic transfers. https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki Instead of TX0, TX1, etc, can you put some kind of meaningful identifier for these transactions? TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both parties. After TX0 is signed, but before TX2 is signed, either party could walk away or otherwise hold the funds hostage. The sequence of signing proposed in this BIP is *not possible to perform*. How did you implement and test this? :/ What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use... IMO, there should be separate BIPs for the exchange itself, and the protocol to negotiate the exchange. I would recommend changing the latter from JSON-RPC to some extension of the Payment Protocol, if possible. Perhaps it would be good to only support compressed keys, to discourage use of uncompressed ones.. Luke -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol
On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr l...@dashjr.org wrote: Instead of TX0, TX1, etc, can you put some kind of meaningful identifier for these transactions? Sorry, that is the names come from the original thread, where I was outlining the idea. I updated the names. TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both parties. The bail in transactions are only signed by one of the parties. They are kept secret until the refund/payout transactions are all properly signed. There is a malleability risk though, hence the need for the 3rd party. It works on the same refund principle as payment channels. After TX0 is signed, but before TX2 is signed, either party could walk away or otherwise hold the funds hostage. The sequence of signing proposed in this BIP is *not possible to perform*. TX0 is not broadcast until the refund transactions are complete. How did you implement and test this? :/ This is a draft at the moment. There is an implementation of (almost) this system but not by me. This proposal reduces the number of non-standard transaction types required. A full implement is the next step. What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use... That is a typo, I have updated it. IMO, there should be separate BIPs for the exchange itself, and the protocol to negotiate the exchange. I can do that. I would recommend changing the latter from JSON-RPC to some extension of the Payment Protocol, if possible. I wanted it to be as simple as possible, but I guess MIME is just a different way of doing things. Perhaps it would be good to only support compressed keys, to discourage use of uncompressed ones.. I would have no objection. Luke -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP Draft: Atomic Cross Chain Transfer Protocol
I updated again. The new version only requires non-standard transactions on one of the two networks. Next step is a simple TCP / RPC server that will implement the protocol to trade between testnet and mainnet. Timeouts of much less than 24 hours should be possible now. On Wed, Apr 30, 2014 at 9:48 PM, Tier Nolan tier.no...@gmail.com wrote: On Wed, Apr 30, 2014 at 7:59 PM, Luke Dashjr l...@dashjr.org wrote: Instead of TX0, TX1, etc, can you put some kind of meaningful identifier for these transactions? Sorry, that is the names come from the original thread, where I was outlining the idea. I updated the names. TX1 and TX2 *cannot* be signed until after TX0 is completely signed by both parties. The bail in transactions are only signed by one of the parties. They are kept secret until the refund/payout transactions are all properly signed. There is a malleability risk though, hence the need for the 3rd party. It works on the same refund principle as payment channels. After TX0 is signed, but before TX2 is signed, either party could walk away or otherwise hold the funds hostage. The sequence of signing proposed in this BIP is *not possible to perform*. TX0 is not broadcast until the refund transactions are complete. How did you implement and test this? :/ This is a draft at the moment. There is an implementation of (almost) this system but not by me. This proposal reduces the number of non-standard transaction types required. A full implement is the next step. What is the purpose of the OP_EQUAL_VERIFY in TX4? I don't see a use... That is a typo, I have updated it. IMO, there should be separate BIPs for the exchange itself, and the protocol to negotiate the exchange. I can do that. I would recommend changing the latter from JSON-RPC to some extension of the Payment Protocol, if possible. I wanted it to be as simple as possible, but I guess MIME is just a different way of doing things. Perhaps it would be good to only support compressed keys, to discourage use of uncompressed ones.. I would have no objection. Luke -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
