Re: [Bitcoin-development] About Compact SPV proofs via block header commitments
I don't think there's an official definition of SPV proof. I wasn't trying to make a argument from definition (that would be fallacious!). Rather I suspected that we had different concepts in mind and wanted to check. That said, I do think that the definition I gave matches how the term is used in the Satoshi whitepaper, and the way in which SPV clients like BitcoinJ work. Best chain is typically taken to mean the most-work, *valid* chain. Without invoking moon math or assumptions of honest peers and jamming-free networks, the only way to know a chain is valid is to witness the each and every block. SPV nodes on the other hand, simply trust that the most-work chain is a valid chain, based on economic arguments about the opportunity cost of mining invalid blocks. These SPV nodes use block headers as proofs to determine the most-work block connected to the genesis block or most recent checkpoint. So yes, operationally at least this is what the community seems to mean by SPV proof. Now regarding your use case: For the remaining peers, the client starts asking for parents blocks until all parents agree (this is the last common parent). This linear scan of block headers is what I would prefer to avoid. By using back-links you make it have log(N) space usage. On 04/26/2014 07:39 PM, Sergio Lerner wrote: El 26/04/2014 10:43 p.m., Mark Friedenbach escribió: Sergio, First of all, let's define what an SPV proof is: it is a succinct sequence of bits which can be transmitted as part of a non-interactive protocol that convincingly establishes for a client without access to the block chain that for some block B, B has an ancestor A at some specified height and work distance back, and the cost of creating a false proof is at least as much work as it claims to represent. Ok. I was thinking with another definition SPV proof. For me a SPV proof is a sequence of bits which can be transmitted as part of a non-interactive protocol that convincingly establishes for a client without access to the block chain that a block B is part of the best-chain. I understand that SPV nodes require SPV proofs as defined in my definition, but I can't realize how to prove that SPV nodes require SPV proofs under your definition. So your definition sounds to me like one possible solution, but not the need. Is your definition something well-established in the community? -- 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] Compatibility Bitcoin-Qt with Tails
Sample terminal output for latest Tails (0.23): amnesia@amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt Bus::open: Can not get ibus-daemon's address. IBusInputContext::createInputContext: no connection to ibus-daemon sendto: Operation not permitted Segmentation fault amnesia@amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt Segmentation fault amnesia@amnesia:~/linux-4765b8c-gitian-2d48b96/32$ ./bitcoin-qt -proxy=127.0.0.1:9050 Segmentation fault Can you get a traceback? 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
[Bitcoin-development] Proposal for extra nonce in block header
I'd like to put the following draft of a BIP up for discussion. Timo # Abstract There are incentives for miners to find cheap, non-standard ways to generate new work, which are not necessarily in the best interest of the protocol. In order to reduce these incentives this proposal re-assigns 2 bytes from the version field of the block header to a new extra nonce field. # Copyright # Specification The block version number field in the block header is reduced in size from 4 to 2 bytes. The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header. # Motivation The motivation of this proposal is to provide miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree. Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse. # Rationale Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block. After incrementing the extra nonce the minimum amount of work a miner has to do to re-calculate the block header is a) to hash the coinbase transaction and b) to re-calculate the left-most branch of the merkle tree all the way to the merkle root. This is necessary overhead a miner has to do besides hashing the block header itself. We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_. First it should be noted that the relative cost of pre-hashing in its traditional form depends on the block size, which may create an unwanted incentive for miners to keep the block size small. However, this is not the main motivation for the current proposal. While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required. Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases. This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing. An example of this currently happening is the on-device rolling of the timestamp into the future. These ways of creating new work are unlikely to be in the best interest of the protocol. For example, rolling the timestamp faster than the real time is unwanted (more so on faster blockchains). The version number in the block header is a possible target for alteration with the goal of cheaply creating new work. Currently, blocks with arbitrarily large version numbers get relayed and accepted by the network. As this is unwanted behaviour, there should not exist any incentive for a miner to abuse the version number in this way. The solution is to reduce the range of version numbers from 2^32 to 2^16 and to declare the third and forth bytes of the block header as legitimate space for an extra nonce. This will reduce the incentive for a miner to abuse the shortened version number by a factor in the order of 2^16. As a side effect, this proposal greatly reduces the bandwidth requirements of a blind pool protocol by only submitting the block header to the miner. # Backwards Compatibility Old versions of the client will accept blocks of this kind but will throw an alert at the user to upgrade. The only code change would be a cast of the version number to a short. Besides the upgrade alert, old and new versions of the client can co-exist and there is no need to introduce a new block version number or to phase-out old block versions. # Reference Implementation # Final implementation -- Timo Hanke PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8 -- 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] Error handling in payment protocol (BIP-0070 and BIP-0072)
Keep in mind that links don't always come embedded in html. Think of native mobile apps. On Sat, Apr 26, 2014 at 10:43 AM, Ross Nicoll j...@jrn.me.uk wrote: I'd be very cautious of security implications of embedding files into the payment request. Even file formats one would presume safe, such as images, have had security issues (i.e. https://technet.microsoft.com/library/security/ms11-006 ) Longer term I was wondering about embedding the PaymentRequest into web pages directly via the object tag, which could eliminate need for BIP0072 and potentially improve user interface integration that way. Obviously this would require browser plugins, however. Ross On 26/04/14 18:36, Mike Hearn wrote: PaymentRequests are limited to 50,000 bytes. I can't think of a reason why Payment messages would need to be any bigger than that. Submit a pull request to the existing BIP. In future it might be nice to have images and things in the payment requests, to make UIs look prettier. But with the current version 50kb should be plenty indeed. -- 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] Proposal for extra nonce in block header
On 27 April 2014 09:07, Timo Hanke timo.ha...@web.de wrote: I'd like to put the following draft of a BIP up for discussion. Timo # Abstract There are incentives for miners to find cheap, non-standard ways to generate new work, which are not necessarily in the best interest of the protocol. In order to reduce these incentives this proposal re-assigns 2 bytes from the version field of the block header to a new extra nonce field. # Copyright # Specification The block version number field in the block header is reduced in size from 4 to 2 bytes. The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header. # Motivation The motivation of this proposal is to provide miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree. Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse. # Rationale Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block. After incrementing the extra nonce the minimum amount of work a miner has to do to re-calculate the block header is a) to hash the coinbase transaction and b) to re-calculate the left-most branch of the merkle tree all the way to the merkle root. This is necessary overhead a miner has to do besides hashing the block header itself. We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_. First it should be noted that the relative cost of pre-hashing in its traditional form depends on the block size, which may create an unwanted incentive for miners to keep the block size small. However, this is not the main motivation for the current proposal. While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required. Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases. This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing. An example of this currently happening is the on-device rolling of the timestamp into the future. These ways of creating new work are unlikely to be in the best interest of the protocol. For example, rolling the timestamp faster than the real time is unwanted (more so on faster blockchains). The version number in the block header is a possible target for alteration with the goal of cheaply creating new work. Currently, blocks with arbitrarily large version numbers get relayed and accepted by the network. As this is unwanted behaviour, there should not exist any incentive for a miner to abuse the version number in this way. The solution is to reduce the range of version numbers from 2^32 to 2^16 and to declare the third and forth bytes of the block header as legitimate space for an extra nonce. This will reduce the incentive for a miner to abuse the shortened version number by a factor in the order of 2^16. As a side effect, this proposal greatly reduces the bandwidth requirements of a blind pool protocol by only submitting the block header to the miner. # Backwards Compatibility Old versions of the client will accept blocks of this kind but will throw an alert at the user to upgrade. The only code change would be a cast of the version number to a short. Besides the upgrade alert, old and new versions of the client can co-exist and there is no need to introduce a new block version number or to phase-out old block versions. # Reference Implementation # Final implementation If changing the structure of the block header, wouldnt you also need to increment the version number to 3? -- Timo Hanke PGP 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8 -- 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
Re: [Bitcoin-development] Proposal for extra nonce in block header
I'm not convinced of the necessity of this idea in general, but if it were to be implemented I would recommend serializing the nVersion field as a VarInt (Pieter Wuille's multi-byte serialization format) and using the remaining space of the 4 bytes as your extra nonce. That would allow serialization of numbers up to 0x1020407f (slightly over 28 bits) before the 4-byte field is exhausted. For version numbers less than 0x204080 there will be at least one byte of padding space left over for extra-nonce usage (two bytes if less than 0x4080, three bytes if less than 0x80). For version values up to 127, the format is exactly identical when the padding bytes are zero. On 04/27/2014 12:07 AM, Timo Hanke wrote: I'd like to put the following draft of a BIP up for discussion. Timo # Abstract There are incentives for miners to find cheap, non-standard ways to generate new work, which are not necessarily in the best interest of the protocol. In order to reduce these incentives this proposal re-assigns 2 bytes from the version field of the block header to a new extra nonce field. # Copyright # Specification The block version number field in the block header is reduced in size from 4 to 2 bytes. The third and fourth byte in the block header are assigned to the new extra nonce field inside the block header. # Motivation The motivation of this proposal is to provide miners with a cheap constant-complexity method to create new work that does not require altering the transaction tree. Furthermore, the motivation is to protect the version and timestamp fields in the block header from abuse. # Rationale Traditionally, the extra nonce is part of the coinbase field of the generation transaction, which is always the very first transaction of a block. After incrementing the extra nonce the minimum amount of work a miner has to do to re-calculate the block header is a) to hash the coinbase transaction and b) to re-calculate the left-most branch of the merkle tree all the way to the merkle root. This is necessary overhead a miner has to do besides hashing the block header itself. We shall call the process that leads to a new block header from the same transaction set the _pre-hashing_. First it should be noted that the relative cost of pre-hashing in its traditional form depends on the block size, which may create an unwanted incentive for miners to keep the block size small. However, this is not the main motivation for the current proposal. While the block header is hashed by ASICs, pre-hashing typically happens on a CPU because of the greater flexibility required. Consequently, as ASIC cost per hash performance drops the relative cost of pre-hashing increases. This creates an incentive for miners to find cheaper ways to create new work than by means of pre-hashing. An example of this currently happening is the on-device rolling of the timestamp into the future. These ways of creating new work are unlikely to be in the best interest of the protocol. For example, rolling the timestamp faster than the real time is unwanted (more so on faster blockchains). The version number in the block header is a possible target for alteration with the goal of cheaply creating new work. Currently, blocks with arbitrarily large version numbers get relayed and accepted by the network. As this is unwanted behaviour, there should not exist any incentive for a miner to abuse the version number in this way. The solution is to reduce the range of version numbers from 2^32 to 2^16 and to declare the third and forth bytes of the block header as legitimate space for an extra nonce. This will reduce the incentive for a miner to abuse the shortened version number by a factor in the order of 2^16. As a side effect, this proposal greatly reduces the bandwidth requirements of a blind pool protocol by only submitting the block header to the miner. # Backwards Compatibility Old versions of the client will accept blocks of this kind but will throw an alert at the user to upgrade. The only code change would be a cast of the version number to a short. Besides the upgrade alert, old and new versions of the client can co-exist and there is no need to introduce a new block version number or to phase-out old block versions. # Reference Implementation # Final implementation -- 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] About Compact SPV proofs via block header commitments
El 27/04/2014 03:43 a.m., Mark Friedenbach escribió: I don't think there's an official definition of SPV proof. I wasn't trying to make a argument from definition (that would be fallacious!). Rather I suspected that we had different concepts in mind and wanted to check. So to disambiguate I define the most general definition as a NPP (non-interactive payment proof). Without invoking moon math or assumptions of honest peers and jamming-free networks, the only way to know a chain is valid is to witness the each and every block. SPV nodes on the other hand, simply trust that the most-work chain is a valid chain, based on economic arguments about the opportunity cost of mining invalid blocks. I argue that you cannot talk about the most-work chain without actually making an assumption about honest peers. If you do not make the assumption, you compute the economic arguments wrong. Now regarding your use case: For the remaining peers, the client starts asking for parents blocks until all parents agree (this is the last common parent). This linear scan of block headers is what I would prefer to avoid. By using back-links you make it have log(N) space usage. First this is a method that uses NPPs, not SPV proofs. Since the method chooses all peers that are synchronized (have the latest current block) then going back means only skipping a potential short fork (which I suppose has never been more than 3 blocks during normal network conditions). You're looking for a common ancestor, not the checkpoint. So the linear scan is actually O(1). The exact value can be approximated by the sum of the convergent infinite geometrical sequence of forking probabilities, which it's about 1.03 without considering selfish-mining, and probably less than 2.03 considering it. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
On 27/04/14 11:42, Christophe Biocca wrote: This seems like splitting hairs, no? A block isn't a guarantee (it can get orphaned). And as a user of bitcoin (as opposed to a miner), this change cannot affect any payment you ever receive. Disagree. Maybe we just have a fundamental disagreement about what Bitcoin is? :) Bitcoin is this perfect /trustless/ mathematical machine, built - most unfortunately - upon a foundation of mushy humans. We depend specifically upon these three assumptions: 1. 50% of hashpower will not cooperate to rewrite history 2. the economic majority will not cooperate to reinterpret history 3. enough people believe in the illusion of artificial scarcity to give it real value Given that the above hold, from there up the system operates completely trustlessly, with predictable security parameters. (Of course a block isn't a guarantee of anything, but I know the probability that you can cause a re-org from depth N with X% hashpower, which allows me to reason about security.) Now, some people on this thread might point to the above 3 points and say that isn't really a trustless system, it's a democratic system. And then advocate that we can do without assumption 2, replacing it with: 2. the economic majority will not cooperate to reinterpret history against any good guys, only against bad guys; please trust their good judgement. That moves us away from a pure trustless system built upon a small democratic foundation (as something of a necessary evil in an imperfect world where humans run our computers and use our system) and toward a democratic system. You don't have to agree, but I hope you can understand the point I'm making :-) It's a fundamental shift in the nature of the system, and to some people a violation of the social contract. Definitely not splitting hairs. I feel I've now consumed rather more bytes of everyone's inboxes than I ought to have with this topic. I appreciate you and Mike taking the time to reply to a newbie/lurker. -Gareth signature.asc Description: OpenPGP 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
That moves us away from a pure trustless system built upon a small democratic foundation (as something of a necessary evil in an imperfect world where humans run our computers and use our system) and toward a democratic system. You don't have to agree, but I hope you can understand the point I'm making :-) Yep, your point is well made. I don't have much more to say about this proposal specifically, but I think this whole question of what changes are OK and what would be a violation of the social contract will get discussed endlessly over the coming years. Put another way, what do Bitcoin's users expect and want - a system that evolves or a system that remains exactly as they found it? There will be good arguments on both sides, and the answer will probably be different on a case by case basis. But personally I'm skeptical of any argument that argues against change for its own sake. It has to be an argument rooted in a careful analysis of costs and benefits. -- 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] About Compact SPV proofs via block header commitments
On 04/27/2014 05:36 AM, Sergio Lerner wrote: Without invoking moon math or assumptions of honest peers and jamming-free networks, the only way to know a chain is valid is to witness the each and every block. SPV nodes on the other hand, simply trust that the most-work chain is a valid chain, based on economic arguments about the opportunity cost of mining invalid blocks. I argue that you cannot talk about the most-work chain without actually making an assumption about honest peers. I should have said without invoking moon math or interactive protocols requiring honest peers over jamming-free networks. The interactive protocol was more the point than the honest peers and jamming-free network. Yes, without an honest peer and an un-jammed network, you might never learn about the most-work chain in the first place. But having the security of the proof not depend on query access to an honest full node is absolutely necessary for some applications and certainly desirable in others. Although strictly speaking what I said may not be 100% true. The single alternative solution I've seen involves some sort of Fiat–Shamir transform that could give you a probabilistic proof by including random additional paths through the block chain chosen based on the combined hash of the headers. However this is disadvantageous as it massively increases the proof size and verification time, and you have to include a lot of data to achieve assurance that more work was required to generate the fraud than an honest chain. If you do not make the assumption, you compute the economic arguments wrong. Not necessarily. By requiring connectivity you know that what you are receiving is built off of the main chain, for example, and you can still make assumptions about resulting opportunity costs. First this is a method that uses NPPs, not SPV proofs. Since the method chooses all peers that are synchronized (have the latest current block) then going back means only skipping a potential short fork (which I suppose has never been more than 3 blocks during normal network conditions). You're looking for a common ancestor, not the checkpoint. So the linear scan is actually O(1). The exact value can be approximated by the sum of the convergent infinite geometrical sequence of forking probabilities, which it's about 1.03 without considering selfish-mining, and probably less than 2.03 considering it. Unless you're connected to attacker nodes which are wildly divergent from each other. It's relatively easy to create a massive fake history of difficulty-1 blocks. If you assume honest peers things get very easy. But that's not a safe assumption to be making. With back-link block-history commitments, on the other hand, an interactive protocol allows you to do a binary search to find common ancestors, and have trust that the intermediate links actually exist. -- 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
Agreed. I'm a pragmatist, certainly not anti-change (or even anti-zero-conf.) Useful and non-controversial hard forks don't keep me awake at night :) I support your general position on zero-conf payments (that they're useful and we should make them as reliable as practical.) But the very essence of Bitcoin, to me, is trustlessness. Satoshi's great invention isn't just another payment network - it's /ecash/. Bearer-negotiable, whoever-controls-the-private-keys-owns-it, **ecash**. If not that, what do you think it is? :-) I like trustless systems for purely pragmatic, cost-benefit reasons. They allow us to avoid all the costs associated with imperfect humans, while reaping the benefits of reliability and predictability :P On 28 April 2014 12:31:05 AM AEST, Mike Hearn m...@plan99.net wrote: That moves us away from a pure trustless system built upon a small democratic foundation (as something of a necessary evil in an imperfect world where humans run our computers and use our system) and toward a democratic system. You don't have to agree, but I hope you can understand the point I'm making :-) Yep, your point is well made. I don't have much more to say about this proposal specifically, but I think this whole question of what changes are OK and what would be a violation of the social contract will get discussed endlessly over the coming years. Put another way, what do Bitcoin's users expect and want - a system that evolves or a system that remains exactly as they found it? There will be good arguments on both sides, and the answer will probably be different on a case by case basis. But personally I'm skeptical of any argument that argues against change for its own sake. It has to be an argument rooted in a careful analysis of costs and benefits. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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 for P2SH multisig wallets
On Sat, Apr 26, 2014 at 6:08 AM, Thomas Voegtlin thoma...@gmx.de wrote: Perhaps the only thing that needs to be standardized is the order of public keys in the redeem script: I think they should be sorted, so that the p2sh address does not depend on the order of pubkeys. Yes. That solution is already implemented in a few wallets. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- 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
