Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Update: BIP 79 has been implemented in the latest release of Electrum, v2.3.2: https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES -Kristov On Fri, Jun 12, 2015 at 5:36 PM, Kristov Atlas kristovatlas.li...@gmail.com wrote: Since everyone's busy, I went ahead and made a pull request to add this as an informational BIP 79 to the bips directory. https://github.com/bitcoin/bips/pull/157 Regards, Kristov On Tue, Jun 9, 2015 at 4:14 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote: Two other things: On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd p...@petertodd.org wrote: Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized protocols; you haven't taken into account the needs of those protocols. For BIP's it's better to stick to the use-cases where the need is clear and there exists running code that to speculate too much on future uses. With signature hashing in particular it's not yet clear at all what future OP_CHECKSIG's will look like, let alone the various ways people will use sighash for smart contract type stuff. You'd be better off presenting the BIP in terms of a generic statement that except when otherwise prevented by advanced signature hashing requirements, wallet software must emit transactions sorted according to the following You can then specify the two common cases in detail: 1) SIGHASH_ALL: input and output order signed, so sort appropriately 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit transactions sorted, recognising that the actual mined order may be changed. That makes sense. I updated the language as follows -- your thoughts? Keep in mind this BIP is informational, and so people are free to ignore it. Applicability: This BIP applies to all transactions of signature hash type SIGHASH_ALL. Additionally, software compliant with this BIP that allows later parties to update the transaction (e.g. using signature hash types SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit lexicographically sorted inputs and outputs, although they may later be modified. Transactions that have index dependencies between transactions or within the same transaction are covered under the section of this BIP entitled “Handling Input/Output Dependencies.” I'd keep it even simpler than that, and just say for now that such use-cases are out of the scope of this BIP, however those standards should come up with some kind of deterministic standard that meets the needs of the protocol. Again, there's a bunch of possible use-cases here and we just can't predict them; focus on the fact that the *spirit* of what this BIP is about is applicable and future standards should be developed. So I'd change the Applicability section to: This BIP applies to all transactions where the order of inputs and outputs does not matter. This is true for the vast majority of transactions as they simply move funds from one place to another. Currently this generally refers to transactions where SIGHASH_ALL is used, in which case the signatures commit to the exact order of input and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE has been used (e.g. crowdfunds) the order of inputs and/or outputs may not be signed, however compliant software should still emit transactions with sorted inputs and outputs, even though they may later be modified by others. In the event that future protocol upgrades introduce new signature hash types, compliant software should apply the lexographic ordering principle analogously. While out of scope of this BIP, protocols that do require a specified order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should consider the goals of this BIP and how best to adapt them to the specifics needs of those protocols. Then remove the handling input/output deps section. Do you have a patch implementing deterministic tx ordering for Bitcoin Core yet? I'm not a frequent C programmer, so I'd prefer to let someone else take care of it, as a frequent committer of code would do a faster and more stylistically consistent job of it. If no one else will, however, I will. re: the actual ordering algorithm, having txids be sorted by with the hex-based algorithm is odd. I'd simply say they're sorted as little-endian byte arrays, or in other words, with the bytearr_cmp() function, but with the order of bytes reversed. You also should say that we're doing that to make the user see them in visually sorted order to match expectations because txids are displayed as little-endian. For outputs, don't say locking script, say scriptPubKey. Secondly, scriptPubKeys are not in little-endian representation - they have no endianness to them. With output amount, there's no need to say that they're unsigned or little-endian satoshies
Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Thanks for the feedback. I think I have reflected all of your requested changes in the latest version, in the BIP and sample code: https://github.com/kristovatlas/rfc/tree/master/bips -Kr On Tue, Jun 9, 2015 at 4:14 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote: Two other things: On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd p...@petertodd.org wrote: Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized protocols; you haven't taken into account the needs of those protocols. For BIP's it's better to stick to the use-cases where the need is clear and there exists running code that to speculate too much on future uses. With signature hashing in particular it's not yet clear at all what future OP_CHECKSIG's will look like, let alone the various ways people will use sighash for smart contract type stuff. You'd be better off presenting the BIP in terms of a generic statement that except when otherwise prevented by advanced signature hashing requirements, wallet software must emit transactions sorted according to the following You can then specify the two common cases in detail: 1) SIGHASH_ALL: input and output order signed, so sort appropriately 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit transactions sorted, recognising that the actual mined order may be changed. That makes sense. I updated the language as follows -- your thoughts? Keep in mind this BIP is informational, and so people are free to ignore it. Applicability: This BIP applies to all transactions of signature hash type SIGHASH_ALL. Additionally, software compliant with this BIP that allows later parties to update the transaction (e.g. using signature hash types SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit lexicographically sorted inputs and outputs, although they may later be modified. Transactions that have index dependencies between transactions or within the same transaction are covered under the section of this BIP entitled “Handling Input/Output Dependencies.” I'd keep it even simpler than that, and just say for now that such use-cases are out of the scope of this BIP, however those standards should come up with some kind of deterministic standard that meets the needs of the protocol. Again, there's a bunch of possible use-cases here and we just can't predict them; focus on the fact that the *spirit* of what this BIP is about is applicable and future standards should be developed. So I'd change the Applicability section to: This BIP applies to all transactions where the order of inputs and outputs does not matter. This is true for the vast majority of transactions as they simply move funds from one place to another. Currently this generally refers to transactions where SIGHASH_ALL is used, in which case the signatures commit to the exact order of input and outputs. In the case where SIGHASH_ANYONECANPAY and/or SIGHASH_NONE has been used (e.g. crowdfunds) the order of inputs and/or outputs may not be signed, however compliant software should still emit transactions with sorted inputs and outputs, even though they may later be modified by others. In the event that future protocol upgrades introduce new signature hash types, compliant software should apply the lexographic ordering principle analogously. While out of scope of this BIP, protocols that do require a specified order of inputs/outputs (e.g. due to use of SIGHASH_SINGLE) should consider the goals of this BIP and how best to adapt them to the specifics needs of those protocols. Then remove the handling input/output deps section. Do you have a patch implementing deterministic tx ordering for Bitcoin Core yet? I'm not a frequent C programmer, so I'd prefer to let someone else take care of it, as a frequent committer of code would do a faster and more stylistically consistent job of it. If no one else will, however, I will. re: the actual ordering algorithm, having txids be sorted by with the hex-based algorithm is odd. I'd simply say they're sorted as little-endian byte arrays, or in other words, with the bytearr_cmp() function, but with the order of bytes reversed. You also should say that we're doing that to make the user see them in visually sorted order to match expectations because txids are displayed as little-endian. For outputs, don't say locking script, say scriptPubKey. Secondly, scriptPubKeys are not in little-endian representation - they have no endianness to them. With output amount, there's no need to say that they're unsigned or little-endian satoshies, just say they're sorted largest/smallest amount first. For the sake of efficiency, amounts will be considered first for sorting, since they contain fewer bytes of information (7 bytes) compared to a standard P2PKH locking script (800
Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Hey Peter, thanks for your experienced feedback. On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd p...@petertodd.org wrote: Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized protocols; you haven't taken into account the needs of those protocols. For BIP's it's better to stick to the use-cases where the need is clear and there exists running code that to speculate too much on future uses. With signature hashing in particular it's not yet clear at all what future OP_CHECKSIG's will look like, let alone the various ways people will use sighash for smart contract type stuff. You'd be better off presenting the BIP in terms of a generic statement that except when otherwise prevented by advanced signature hashing requirements, wallet software must emit transactions sorted according to the following You can then specify the two common cases in detail: 1) SIGHASH_ALL: input and output order signed, so sort appropriately 2) SIGHASH_ANYONECANPAY: input order not signed, so software should emit transactions sorted, recognising that the actual mined order may be changed. That makes sense. I updated the language as follows -- your thoughts? Keep in mind this BIP is informational, and so people are free to ignore it. Applicability: This BIP applies to all transactions of signature hash type SIGHASH_ALL. Additionally, software compliant with this BIP that allows later parties to update the transaction (e.g. using signature hash types SIGHASH_NONE or a variant of SIGHASH_ANYONECANPAY) should emit lexicographically sorted inputs and outputs, although they may later be modified. Transactions that have index dependencies between transactions or within the same transaction are covered under the section of this BIP entitled “Handling Input/Output Dependencies.” As for IsStandard() rules - let alone soft forks - better to leave discussion of them out for now. In particular, for the soft-fork case mandating certain transaction orders will very likely cause problems in the future for future OP_CHECKSIG upgrades. For SIGHASH_ANYONECANPAY, it might be appropriate for nodes to enforce a certain ordering, but that can be a separate BIP. (actually implementing that in Bitcoin Core would be annoying and ugly right now; without replace-by-fee ANYONECANPAY has a silly DoS attack (adding low-fee inputs) so I can't recommend wallets use it in the general case yet) and a sequence number currently set to 0x. - Actually, this will be changed in Bitcoin Core as of v0.11.0, which implements anti-fee-sniping w/ nLockTime.(1) (I need to write up a full BIP describing it) Thanks for the heads-up; removed. Do you have a patch implementing deterministic tx ordering for Bitcoin Core yet? I'm not a frequent C programmer, so I'd prefer to let someone else take care of it, as a frequent committer of code would do a faster and more stylistically consistent job of it. If no one else will, however, I will. -Kristov -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
As for IsStandard() rules - let alone soft forks - better to leave discussion of them out for now. Removed that bit as well. Latest version: https://github.com/kristovatlas/rfc/blob/master/bips/bip-li01.mediawiki -Kristov -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs
Hey Stephen, Thanks for your feedback On Fri, Jun 5, 2015 at 11:20 PM, Stephen stephencalebmo...@gmail.com wrote: - I think your explanation of sorting could be significantly shortened and clarified by simply saying that the TXIDs of inputs should be compared as uint256 integers. I considered defining the comparison of txids in terms of integers; however, I am concerned that this definition may be ambiguous when applied to a variety of languages and platforms without a similar amount of explanation as currently exists. For example, if a web wallet uses an API to receive transaction information, this is traditionally expressed in terms tx id strings rather than 256-bit integers. My intent is that wallets can implement the algorithm however they wish, but should ensure that their output is compliant with the BIP definition. IMHO the algorithm stated in the BIP should target test cases rather than implementation, and should leave as little room for ambiguity as possible. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Tough questions for Peter Todd, Chief Scientist {Mastercoin | Counterparty | Coinkite | Darkwallet | Viacoin}
Why would Peter be accountable to you in any shape or form? What contact did he sign onto with you? -Kr On Jun 4, 2015 5:52 PM, Sven Berg svenb...@airmail.cc wrote: 1) Hours/week have you devoted to each project out of a 40hr work week 2) Upfront and ongoing fees for use of your name 3) Break down total amounts for each project 4) Start dates of contracts for each project 5) End dates (if applicable) 6) Current and past holdings of altcoins/appcoins (including liquidation dates) 7) Describe return on investment to investors related to your activities during employment (other than marketing/price pump) 8) Describe your involvement with Initial Coin Offers (ICO) of applicable 9) Explain rational for pursuit of ICO fund sources rather than community/established businesses (Lighthouse, legit startups, etc.) -- Berg Investigations LLC. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Request for Comment: Bitcoin Wallet Privacy Ratings Criteria
The Open Bitcoin Privacy Project is seeking public comment on our ratings criteria for Bitcoin wallet privacy. Please provide your feedback within the next week through Jan 23, 2015 to ensure that it will be considered for version 1.0 of the document. https://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/criteria.md In conjunction with a scoring matrix that will determine the weight of each sub-category, this criteria will be used to evaluate and score a variety of Bitcoin wallets, which will be published on our website at openbitcoinprivacyproject.org. Feedback through this mailing list is, of course, welcome; if you have a GitHub account, this is the preferred medium for proposing changes to the document. The current version of the criteria was authored by myself, as well as other OBPP members including Justus Ranvier (Monetas), Chris Pacia (Bitcoin Authenticator), and Samuel Patterson (Open Bazaar). Thank you in advance for your feedback, Kristov Atlas kristovat...@gmail.com aut...@anonymousbitcoinbook.com -- New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoinj 0.12
Congrats, and thanks for your hard work. I hate to reply to a release that includes a huge number of new features with yet another feature request, so -- with apologies -- any plans for bitcoinj to support stealth address sending and/or receiving? https://wiki.unsystem.net/en/index.php/DarkWallet/Stealth Sincerely, Kristov Atlas On Oct 3, 2014 8:50 AM, Mike Hearn m...@plan99.net wrote: I’m pleased to announce version 0.12 of bitcoinj, one of the worlds most popular Bitcoin libraries. It is used by at least four Android wallets, three desktop wallets, blockchain.info, Circle, biteasy, CryptoCorp, Lighthouse, BlueMatt’s relay network, bitpos, countless alt coin wallets, for academic research projects and much more. This release represents 8 months of work. The biggest new feature is HD wallets. Other notable enhancements include a bundled Tor client that can be activated with one line of code, support for multisig wallets, much faster and deterministic ECDSA, many API improvements and big upgrades to the included GUI wallet which can be seen in a new screencasted tutorial https://bitcoinj.github.io/simple-gui-wallet. The commit hash of bitcoinj 0.12 is 83a9a71f3fff3f223d0737ad758b519a39dbbd62. New in this release - Privacy enhancements: - Wallets are now hierarchical and deterministic (HD) by default, using the BIP32 specification. Support for mnemonic codes (BIP 39) is also included. Change and receive addresses are no longer being reused. Old wallets are upgraded in place using the private key of the oldest non-rotating key as the seed bytes, so old backups remain valid. - Thanks to devrandom, we have an integrated Tor mode using the Orchid library. The user does not have to install the Tor client as it’s all pure Java. WalletAppKit users can enable usage of Tor with a single line of code. This support should be considered experimental for now. - Thanks to Kosta Korenkov, we have an experimental multisig wallets implementation. Multisig (also “married”) wallets are HD wallets that are connected to a third party risk analysis service or device. When married, the wallet tracks multiple BIP32 key trees, keeps them in sync and starts vending P2SH addresses. - As part of this work, transaction signing is now pluggable. TransactionSigner implementations can be added to the wallet and will be serialized into and out of the users saved wallet file. Signers are given a transaction to sign in sequence. This is intended for risk analysis providers to provide a class that talks to their server to get a signature of the right form, so that all bitcoinj based wallets can be easily upgraded to support the new provider. - Reject messages are now deserialized and logged, though not yet exposed in the API. - Upgraded to Guava 16 and Bouncy Castle 1.51. Thanks to Peter Dettman and the rest of the Bouncy Castle team, bitcoinj now uses deterministic ECDSA for signing and we’re now using an accelerated secp256k1 implementation that exploits the special properties of this curve, for dramatically faster calculations. - Payment protocol code improvements: Some X.509 utility code was refactored out of PaymentSession for general usage. StartCom was added to the default trust store which was promoted to override the system trust store on non-Android platforms. A command line tool to dump requests to stdout was added. - Thanks to Andreas Schildbach: - We are now BIP62 (canonical push encodings) compliant. - A new Coin class replaces usage of BigInteger for marking values that are quantities of bitcoin. Formatting has moved into the new MonetaryFormat class. - The wallet now saves the fee paid on transactions we calculated ourselves. This is useful for putting it into a wallet user interface. - Transactions can have user memos and exchange rates attached, that will be saved by the wallet. - Support for decrypting BIP 38 protected private keys has been added. - Checkpoints can now be stored textually as well as in the old binary format. - There is also a new BtcFormat API that provides an alternative to MonetaryFormat that plugs in to the java.text framework. - Added new DNS seed from Addy Yeow. - Wallets can now have string-byte[] mappings attached to them, for lighter weight extensions. - Thanks to Richard Green, there is now a Python version of the ForwardingService program from the getting started tutorial. This shows how to use bitcoinj from Python using the Jython interpreter. - bitcoinj now probes localhost for a Bitcoin node and automatically uses that instead of the P2P network, when present. This means any bitcoinj based app can be easily upgraded from SPV to full security just by running
Re: [Bitcoin-development] CoinJoin bounty fund question
On 06/17/2014 06:46 PM, Gregory Maxwell wrote: The correct place for more information is the Bitcointalk forum thread where it was announced: https://bitcointalk.org/index.php?topic=279249.0 Can anyone summarize the current status of the bounty? I see nothing definite about the bounty in that thread from the beginning of January 2014, other than that the multisig address continues to accumulate bitcoins. Meanwhile, on other mailing lists, I've seen some talk about paying a portion or the whole of the bounty to the Dark Wallet team. -Kristov -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ 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
On 04/30/2014 03:02 AM, Wladimir wrote: 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 Nice work! I can confirm that this dev binary runs smoothly in the latest version of Tails, v1.0. Screenshot proof here [1]. When this is incorporated into the next release of Bitcoin Core, will this make the usual Linux binary compatible, or will there be a special binary just for systems running the older Qt? -Kristov [1] http://postimg.org/image/p3ycwai9d/ -- 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] Compatibility Bitcoin-Qt with Tails
On 04/25/2014 04:27 PM, Wladimir wrote: Kristov, I've modified the gitian build so that it builds against Qt 4.6 instead of Qt 4.8 in this pull request: https://github.com/bitcoin/bitcoin/pull/4094 A test build of master with that pulls gitian descriptor is available: https://download.visucore.com/bitcoin/linux-4765b8c-gitian-2d48b96.tar.gz https://download.visucore.com/bitcoin/linux-4765b8c-gitian-2d48b96.tar.gz.sig These bitcoin-qt executables *should* work on Debian Squeeze / Tails Linux. Let me know if it is the case. 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. The segfault came after the usual message that I get when running Bitcoin Core in Tails, which is the sendto: Operation not permitted message since Core will not be able to connect to the internet without going through Tails' Tor SOCKS proxy. When I specify the SOCKS proxy through the command-line, I get a brief flash of the GUI before it segfaults again. The Bus::open and IBusInputContext::createInputContext messages are atypical and might be related to the segfault. 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 -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] Development Roadmap of Bitcoin Core 0.9.2
Yes. Tails 1.1, based on Wheezy, will be out on June 10: https://tails.boum.org/contribute/calendar/ -Kristov Atlas On 04/24/2014 08:18 AM, Wladimir wrote: On Thu, Apr 24, 2014 at 10:25 AM, Wladimir laa...@gmail.com wrote: On Thu, Apr 24, 2014 at 10:15 AM, Warren Togami Jr. wtog...@gmail.com wrote: But indeed we need to decide on a cut-off point. I'd have preferred 4.7 or 4.8. Qt 4.6 is *ancient* - it was released in februari 2010. Apart from tails it doesn't seem like anyone is using those old stable distributions on the desktop. Does anyone know of the timeframe in which tails will switch to a newer version of Qt? As it's debian based: will switch to a Wheezy/7.4. Wheezy has Qt 4.8 so is decidedly unproblematic. I see they're working on migration at least: - https://tails.boum.org/blueprint/Wheezy/ - https://git-tails.immerda.ch/tails/log/?h=feature/wheezy 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 -- 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
