Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?
The mail list is public, so it's not like the data on it is somehow sensitive. Sourcefoge is fine, it has a nice web UI where you can browse the message and sort/order them as you want, etc. Why would you want to move to a paid solution? And why would you want users to have to pay per message? This is the worst idea ever from my point of view. We want to encourage people to join the community, run full nodes, ask questions, come with solutions, ideas for improvements and so on. Everyone should read and write and contribute as much as possible with ideas in debates. You never know who can have bright ideas in some contexts. Bottom line is so far sourceforge handles the mail lists just fine. I don't see a single advantage another mail list provider / system could offer, except some headache and extra work for migration. The software distribution via sourcefoge was cancelled for obvious reasons which I fully understand and agree to, but it has nothing to do with the mail lists. We have way more important things to brainstorm about. On 6/10/2015 7:46 PM, Andy Schroder wrote: Regarding changing the e-mail list provider. Is anyone interested in sponsoring it? There are non-free options, but it may be difficult to always ensure the fee is being paid to the provider. I think finding an agreeable free solution may have been the issue before? I've also thought of trying to make a pay per message or byte solution (and this cost could be dynamic based upon the number of current mailing list subscribers). This could solve the who pays problem (the sender pays), as well as motivate people to be more concise and clear with their messages, and at the same time limit spam. Any thoughts? Andy Schroder On 06/10/2015 05:35 AM, Wladimir J. van der Laan wrote: On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote: http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/ All our downloads (even old ones) have recently been deleted from sourceforge, for this reason. They haven't been mentioned in Bitcon Core release announcements for a long time. No opinion on the mailing list. Though I think it's less urgent. The issue of moving the mailinglist has come up before a few times and people can't agree where to move to. Wladimir -- -- ___ 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
Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
Hi Peter, Thanks for your reply. I know and bookmarked your branch - nice work. So, to clarify: - bitcoin core (official / default) 0.10.x currently has First-seen mempool behavior - your custom branch uses replace by fee mempool behavior which allows an user to change anything in a tx (I guess it needs just to have at least one same input, so it can link it to another previously signed tx with lower fee and substitute it in the mempool, correct?). - First Seen Safe Replace by Fee (FSF-RBF) mempool behavior which allows an user only to add inputs and/or increase the value of outputs will be in yet another branch, maintained by you, but not in default / official bitcoin core? Another thing, if FSF-RBF lets you change TXes in the manner described above, how does the client know which tx needs to be replaced in the mempool? Since the txid naturally changes. How does it map tx1 with tx2 (to know tx2 has a higher fee and needs to substitute tx1) if quite a lot of params from the transaction structure can change? Thanks! On 5/27/2015 4:25 AM, Peter Todd wrote: On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote: What is wrong with the man testing some ideas on his custom branch? This is how improvements come to life. I saw in the BIPs some really interesting ideas and nice brainstorming which came from Peter Todd. Now, my question, if replace by fee doesn't allow me to change the inputs or the outputs, I can only add outputs... what can I do with this feature? If I sent a tx and want to replace it with a higher fee one, the higher fee one can only have maybe additional change addresses or another payment, if the inputs suffice? Do we have any real use cases? You're a bit mistaken there: standard RBF lets you change anything, and FSS RBF lets you modify inputs and add outputs and/or make the value of outputs higher. P.S. is it planned to include this by default in bitcoin core 10.0.3 or it will remain just on Peter's branch? Any significant change to mempool policy like RBF is very unlikely to be incorporated in the Bitcoin Core v0.10.x branch, simply because it'd be too large a change for a minor, mostly bugfix, release. Having said that, I already maintain a standard RBF branch for v0.10.x, and have been asked by a major minor to backport FSS RBF for v0.10.x as well. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%
What is wrong with the man testing some ideas on his custom branch? This is how improvements come to life. I saw in the BIPs some really interesting ideas and nice brainstorming which came from Peter Todd. Now, my question, if replace by fee doesn't allow me to change the inputs or the outputs, I can only add outputs... what can I do with this feature? If I sent a tx and want to replace it with a higher fee one, the higher fee one can only have maybe additional change addresses or another payment, if the inputs suffice? Do we have any real use cases? P.S. is it planned to include this by default in bitcoin core 10.0.3 or it will remain just on Peter's branch? On 5/26/2015 11:30 PM, joli...@airmail.cc wrote: You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks and you have big banks as clients. Shit like replace-by-fee and leading the anti-scaling mob is for your clients, not Bitcoin. Get the fuck out. Peter Todd - 8930511 Canada Ltd. 1214-1423 Mississauga Valley Blvd. Mississauga ON L5A 4A5 Canada https://www.ic.gc.ca/app/scr/cc/CorporationsCanada/fdrlCrpDtls.html?corpId=8930511 On 2015-05-26 00:10, Peter Todd wrote: On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote: CPFP also solves it just fine. CPFP is a significantly more expensive way of paying fees than RBF, particularly for the use-case of defragmenting outputs, with cost savings ranging from 30% to 90% Case 1: CPFP vs. RBF for increasing the fee on a single tx -- Creating an spending a P2PKH output uses 34 bytes of txout, and 148 bytes of txin, 182 bytes total. Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size. I forget to click on the priority fee option, so it goes out with the minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output, creating a new transaction t2 that's 192 bytes in size. I want to pay 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of transaction fees. On the other hand, had I use RBF, my wallet would have simply rebroadcast t1 with the change address decreased. The rules require you to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new fee level, or 218uBTC of fees in total. Cost savings: 48% Case 2: Paying multiple recipients in succession Suppose that after I pay Alice, I also decide to pay Bob for his hard work demonstrating cryptographic protocols. I need to create a new transaction t2 spending t1's change address. Normally t2 would be another 226 bytes in size, resulting in 226uBTC additional fees. With RBF on the other hand I can simply double-spend t1 with a transaction paying both Alice and Bob. This new transaction is 260 bytes in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth consumed broadcasting it, resulting in an additional 36uBTC of fees. Cost savings: 84% Case 3: Paying multiple recipients from a 2-of-3 multisig wallet The above situation gets even worse with multisig. t1 in the multisig case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC in fees. With RBF we rewrite t1 with an additional output, resulting in a 399 byte transaction, with just 36uBTC in additional fees. Cost savings: 90% Case 4: Dust defragmentation My wallet has a two transaction outputs that it wants to combine into one for the purpose of UTXO defragmentation. It broadcasts transaction t1 with two inputs and one output, size 340 bytes, paying zero fees. Prior to the transaction confirming I find I need to spend those funds for a priority transaction at the 1mBTC/KB fee level. This transaction, t2a, has one input and two outputs, 226 bytes in size. However it needs to pay fees for both transactions at once, resulting in a combined total fee of 556uBTC. If this situation happens frequently, defragmenting UTXOs is likely to cost more in additional fees than it saves. With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374 bytes in size, paying 374uBTC. Even better, if one of the two inputs is sufficiently large to cover my costs I can doublespend t1 with a 1-in-2-out tx just 226 bytes in size, paying 226uBTC. Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF costs you more than you save -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
Re: [Bitcoin-development] [BIP] Normalized Transaction IDs
Hello, How will this exactly be safe against: a) the malleability of the parent tx (2nd level malleability) b) replays If you strip just the scriptSig of the input(s), the txid(s) can still be mutated (with higher probability before it gets confirmed). If you strip both the scriptSig of the parent and the txid, nothing can any longer be mutated but this is not safe against replays. This could work if we were using only one scriptPubKey per tx. But this is not enforced, and I don't think it's the proper way to do it. Something similar can be achieved if you would use a combination of flags from here: https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md But this has some issues too. I've read your draft but didn't understand how exactly will this prevent normal malleability as we know it, second level malleability and replays as well as how will we do the transition into mapping the txes in the blockchain to normalized txids. Looking forward to read more on this topic. Thanks for the brainstorming ;) On 5/13/2015 3:48 PM, Christian Decker wrote: Hi All, I'd like to propose a BIP to normalize transaction IDs in order to address transaction malleability and facilitate higher level protocols. The normalized transaction ID is an alias used in parallel to the current (legacy) transaction IDs to address outputs in transactions. It is calculated by removing (zeroing) the scriptSig before computing the hash, which ensures that only data whose integrity is also guaranteed by the signatures influences the hash. Thus if anything causes the normalized ID to change it automatically invalidates the signature. When validating a client supporting this BIP would use both the normalized tx ID as well as the legacy tx ID when validating transactions. The detailed writeup can be found here: https://github.com/cdecker/bips/blob/normalized-txid/bip-00nn.mediawiki. @gmaxwell: I'd like to request a BIP number, unless there is something really wrong with the proposal. In addition to being a simple alternative that solves transaction malleability it also hugely simplifies higher level protocols. We can now use template transactions upon which sequences of transactions can be built before signing them. I hesitated quite a while to propose it since it does require a hardfork (old clients would not find the prevTx identified by the normalized transaction ID and deem the spending transaction invalid), but it seems that hardforks are no longer the dreaded boogeyman nobody talks about. I left out the details of how the hardfork is to be done, as it does not really matter and we may have a good mechanism to apply a bunch of hardforks concurrently in the future. I'm sure it'll take time to implement and upgrade, but I think it would be a nice addition to the functionality and would solve a long standing problem :-) Please let me know what you think, the proposal is definitely not set in stone at this point and I'm sure we can improve it further. Regards, Christian -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Thank you all for your comments. The youtube video was indeed very educative and nice to watch. It's true that malleability is not the end of the world, but it is annoying for contracts and micropayment channels, especially refunds spending the fund tx before it is even in the blockchain, relying solely on its txid. BIP62 is good for preventing 3rd parties (non signers) to mutate txids, but cannot do anything against 2nd parties (signers). I think we can solve both by using NORMALIZEDTXID - wouldn't this be simpler and easier to implement? Why are we talking about P3SH when we can just upgrade P2SH to support additional OP codes? I saw that there have been talks about a hard fork for increasing the block size, might as well take the opportunity and fix this for good, by implementing BIP62, NORMALIZEDTXID as well as BIP65. Couldn't all these be part of P2SH? On 4/25/2015 6:40 PM, Stephen Morse wrote: Hi Gregory, In particular not covering the ID allows for transaction replay which can result in monetary losses far more severe than any possible mishandling of malleability could result in. Byzantine attackers can costlessly replay your old transactions any time anyone reuses an address, even accidentally (which cannot be easily prevented since they can race). With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly specify that they are to be signed without the previous UTXO's value/amount. This means that, at worst, replay attacks can send the money to the same place it was sent before (which in many cases is likely not be a loss of funds), and only if the amount sent to the reused address is the exact same as it was before. I don't think this is worse than an attacker being able to mutate their transaction and extort a merchant who accepts zero-conf transactions. Anyway, not signing the input ID wouldn't exactly be the norm, there would be a defined set of flags for standard use cases. Not signing the input TXID would only be used in specialized cases, such as setting up micropayment channels. There are no free lunches; the proposal linked to there is itself a game of wack-a-mole with assorted masking flags; I agree that it is also a bit of wac-a-mole, but the defined space of issues is possibly more limited here. There are only X number of things that can be signed/not signed in a transaction, and the 'Build your own nHashType' proposal enables you to fully specify which of those are being signed. If you don't want to get burned by not fully signing your transactions, then don't use the non-standard sighash flags. many of which we have no notion of if they're useful for any particular application(s); A few of the flags, indeed, may not ever be useful. But we can't predict the future, and I think it's better to build in a more flexible solution now than to wish we had more flexible nHashTypes later. To the original point of this thread, hopefully the suggested proposal won't be necessary as wallets will upgrade to use version 3 transactions and the rules associated with them over time. Best, Stephen -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Understood. That is unfortunate, but not the end of the world. If you could please give feedback also to these last comments / questions: How far are we at this moment from BIP62? Can an user send a non-malleable tx now, if enforces some additional rules? As for the security of the system, it does not fully rely on txids being non malleable, but see this quote from my previous email: [QUOTE] I am trying to build a bitcoin contract which will relay on 3 things: - coinjoin / txes with inputs from multiple users which are signed by all users after they are merged together (every user is sure his coins will not be spent without the other users to spend anything, as per agreed contract); - pre-signed txes with nLockTime 'n' weeks. These txes will be signed before the inputs being spent are broadcasted/confirmed, using the txid provided by the user before broadcasting it. Malleability hurts here. - P2SH Another thing I would like to confirm, the 3 pieces of the bitcoin protocol mentioned above will be supported in _any_ future transaction version or block version, regardless what changes are made or features added to bitcoin core? The contract needs to be built and left unchanged for a very very long period of time... [/END QUOTE] Can you comment on the quote please? So, basically transaction malleability could affect the system in the way that a pre-signed tx which offers the insurance and which is sent to the user before the user sends the coins (spending user's coins back to him after a certain period of time) could be invalidated. The insurance tx signature will still be good, but invalid overall since the input (txid) being spent does not exist (was altered / modified). The coins won't be stolen or lost, but a new tx needs to be signed with the altered (new) txid, for the system to work. So, an user creates a transaction TX1 sending the coins to the server but does not broadcast it. Instead, he provides the txid of TX1 to the server. Server generates another transaction TX2 which spends TX1 back to the user, with an nLockTime. User checks and if everything ok broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2 will become invalid (since it will be spending an inexistent input), and the server will need to re-create and sign TX2 with the new (altered/modified) txid of TX1, as per agreed contract. Should the server disappear after user broadcasts TX1 and before the altered/modified txid of TX1 gets confirmed, user's coins are forever locked. It is true that no third party can benefit from this type of attack, only the user will result with coins locked, but it is something which could be used by competition to make a service useless / annoying / too complicated or less safe to use. How could I mitigate this? Thanks you for your time and help. On 4/17/2015 12:02 PM, Pieter Wuille wrote: Anyone can alter the txid - more details needed. The number of altered txids in practice is not so high in order to make us believe anyone can do it easily. It is obvious that all current bitcoin transactions are malleable, but not by anyone and not that easy. At least I like to think so. Don't assume that because it does not (frequently) happen, that it cannot happen. Large amounts of malleated transactions have happened in the past. Especially if you build a system depends on non-malleability for its security, you may at some point have an attacker who has financial gain from malleation. From your answer I understand that right now if I create a transaction (tx1) and broadcast it, you can alter its txid at your will, without any mining power and/or access to my private keys so I would end up not recognizing my own transaction and probably my change too (if my systems rely hardly on txid)? In theory, yes, anyone can alter the txid without invalidating it, without mining power and without access to the sender's private keys. All it requires is seeing a transaction on the network, doing a trivial modification to it, and rebroadcasting it quickly. If the modifies version gets mined, you're out of luck. Having mining power helps of course. After BIP62, you will, as a sender, optionally be able to protect others from malleating. You're always able to re-sign yourself. -- Pieter -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Hi Pieter, Thanks for your reply. I agree. Allen has a good point in the previous email too, so the suggestion might not fix anything and complicate things. The problem I am trying to solve is making all transactions non-malleable by default. I guess there is a very good reason why BIP62 will not touch v1 anyway. I am trying to build a bitcoin contract which will relay on 3 things: - coinjoin / txes with inputs from multiple users which are signed by all users after they are merged together (every user is sure his coins will not be spent without the other users to spend anything, as per agreed contract); - pre-signed txes with nLockTime 'n' weeks. These txes will be signed before the inputs being spent are broadcasted/confirmed, using the txid provided by the user before broadcasting it. Malleability hurts here. - P2SH In simple terms, how malleable transactions really are in the network at this moment? Who can alter a txid without invalidating the tx? Just the parties who sign it? The miners? Anyone in the network? This is a little bit unclear to me. Another thing I would like to confirm, the 3 pieces of the bitcoin protocol mentioned above will be supported in _any_ future transaction version or block version, regardless what changes are made or features added to bitcoin core? The contract needs to be built and left unchanged for a very very long period of time... On 4/16/2015 8:22 AM, Pieter Wuille wrote: On Apr 16, 2015 1:46 AM, s7r s...@sky-ip.org mailto:s...@sky-ip.org wrote: but for transaction versions? In simple terms, if 75% from all the transactions in the latest 1000 blocks are version 'n', mark all previous transaction versions as non-standard and if 95% from all the transactions in the latest 1000 blocks are version 'n' mark all previous transaction versions as invalid. What problem are you trying to solve? The reason why BIP62 (as specified, it is just a draft) does not make v1 transactions invalid is because it is opt-in. The creator of a transaction needs to agree to protect it from malleability, and this subjects him to extra rules in the creation. Forcing v3 transactions would require every piece of wallet software to be changed. -- Pieter -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 75%/95% threshold for transaction versions
On 4/16/2015 8:34 PM, Mark Friedenbach wrote: At this moment anyone can alter the txid. Assume transactions are 100% malleable. Anyone can alter the txid - more details needed. The number of altered txids in practice is not so high in order to make us believe anyone can do it easily. It is obvious that all current bitcoin transactions are malleable, but not by anyone and not that easy. At least I like to think so. From your answer I understand that right now if I create a transaction (tx1) and broadcast it, you can alter its txid at your will, without any mining power and/or access to my private keys so I would end up not recognizing my own transaction and probably my change too (if my systems rely hardly on txid)? On Apr 16, 2015 9:13 AM, s7r s...@sky-ip.org mailto:s...@sky-ip.org wrote: Hi Pieter, Thanks for your reply. I agree. Allen has a good point in the previous email too, so the suggestion might not fix anything and complicate things. The problem I am trying to solve is making all transactions non-malleable by default. I guess there is a very good reason why BIP62 will not touch v1 anyway. I am trying to build a bitcoin contract which will relay on 3 things: - coinjoin / txes with inputs from multiple users which are signed by all users after they are merged together (every user is sure his coins will not be spent without the other users to spend anything, as per agreed contract); - pre-signed txes with nLockTime 'n' weeks. These txes will be signed before the inputs being spent are broadcasted/confirmed, using the txid provided by the user before broadcasting it. Malleability hurts here. - P2SH In simple terms, how malleable transactions really are in the network at this moment? Who can alter a txid without invalidating the tx? Just the parties who sign it? The miners? Anyone in the network? This is a little bit unclear to me. Another thing I would like to confirm, the 3 pieces of the bitcoin protocol mentioned above will be supported in _any_ future transaction version or block version, regardless what changes are made or features added to bitcoin core? The contract needs to be built and left unchanged for a very very long period of time... On 4/16/2015 8:22 AM, Pieter Wuille wrote: On Apr 16, 2015 1:46 AM, s7r s...@sky-ip.org mailto:s...@sky-ip.org mailto:s...@sky-ip.org mailto:s...@sky-ip.org wrote: but for transaction versions? In simple terms, if 75% from all the transactions in the latest 1000 blocks are version 'n', mark all previous transaction versions as non-standard and if 95% from all the transactions in the latest 1000 blocks are version 'n' mark all previous transaction versions as invalid. What problem are you trying to solve? The reason why BIP62 (as specified, it is just a draft) does not make v1 transactions invalid is because it is opt-in. The creator of a transaction needs to agree to protect it from malleability, and this subjects him to extra rules in the creation. Forcing v3 transactions would require every piece of wallet software to be changed. -- Pieter -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net mailto:Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] 75%/95% threshold for transaction versions
Hi, Would it be wise to add a consensus rule like the one we have for blocks, (if 75% from last 1000 blocks are version 'n' mark version 'n' as standard for blocks and if 95% from the last 1000 blocks are version 'n' mark previous block versions as invalid) but for transaction versions? In simple terms, if 75% from all the transactions in the latest 1000 blocks are version 'n', mark all previous transaction versions as non-standard and if 95% from all the transactions in the latest 1000 blocks are version 'n' mark all previous transaction versions as invalid. At this moment, the standard in consensus is v1, but nothing is enforced in the network related to transaction versions. Regarding BIP62, as it can be read here [0] it is said that it requires v2 transactions. It is also said that transaction version 2 will be skipped and jump directly to v3, for an even version for transactions and blocks (?). Might as well add the rule for invalidating previous transaction versions if the majority updates - could this break anything or affect functionality in any way? BIP62 adds a newer transaction version which is optional and does not mark previous v1 as non-standard or invalid. This means bitcoin core will treat both v1 and v2/v3 transactions as standard and relay/mine them with the same priority, regardless of the tx version? Thanks. [0] https://bitcoin.stackexchange.com/questions/35904/how-much-of-bip-62-dealing-with-malleability-has-been-implemented -- BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Address Expiration to Prevent Reuse
This should not be enforced by default. There are some use cases where address re-use is justified (a donation address spread on multiple static pages or even printed on papers/books?). For example, I offer some services on the internet for free, and I only have a bitcoin address for donations which is posted everywhere. Obviously this could possibly harm privacy, but not everyone who uses bitcoin wants to keep all transactions private. To the contrary, there are accounting cases when you need to archive all keys, hashes of transactions and everything (for example when using btc inside a company which is required by law to keep accounting registries). I know it's not recommended to use the same pubkey more than once, but the protocol was not designed this way. Enforcing something as described in this topic will undermine an user's rights to re-use his addresses, if a certain situation requires it. On 3/26/2015 11:44 PM, Gregory Maxwell wrote: On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding t...@thinlink.com wrote: I should have been clearer that the motivation for address expiration is to reduce the rate of increase of the massive pile of bitcoin addresses out there which have to be monitored forever for future payments. It could make a significant dent if something like this worked, and were used by default someday. Great, that can be accomplished by simply encoding an expiration into the address people are using and specifying that clients enforce it. -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/28/2014 6:44 AM, Gregory Maxwell wrote: On Sun, Jul 27, 2014 at 7:54 PM, m...@bitwatch.co m...@bitwatch.co wrote: These website list Tor nodes by bandwidth: http://torstatus.blutmagie.de/index.php https://torstatus.rueckgr.at/index.php?SR=BandwidthSO=Desc And the details reveal it's a port 8333 only exit node: http://torstatus.blutmagie.de/router_detail.php?FP=0d6d2caafbb32ba85ee5162395f610ae42930124 As I pointed out above, — it isn't really. Without the exit flag, I believe no tor node will select it to exit 8333 unless manually configured. (someone following tor more closely than I could correct if I'm wrong here) blockchain.info has some records about the related IP going back to the end of this May: https://blockchain.info/ip-address/5.9.93.101?offset=300 dsnrk and mr_burdell on freenode show that the bitnodes crawler showed it accepting _inbound_ bitcoin connections 2-3 weeks ago, though it doesn't now. Fits a pattern of someone running a bitcoin node widely connecting to everyone it can on IPv4 in order to try to deanonymize people, and also running a tor exit (and locally intercepting 8333 there), but I suspect the tor exit part is not actually working— though they're trying to get it working by accepting huge amounts of relay bandwidth. I'm trying to manually exit through it so I can see if its intercepting the connections, but I seem to not be able. Some other data from the hosts its connecting out to proves that its lying about what software its running (I'm hesitant to just say how I can be sure of that, since doing so just tells someone how to do a more faithful emulation; so that that for whatever its worth). -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development The thing is, if it doesn't have the exit flag it cannot generate lots of traffic from real good-intended clients, because it's quite hard for clients to choose this Node as ËXIT in their path if it doesn't have the exit flag. So the traffic comes from clients who specifically added ExitNode fingerprint in their torrc and only use that Tor instance for Bitcoin. So, someone build this custom Tor node for themselves only, for plausible den. A pool could be the cause as it was earlier discussed here... The thing is I cannot find this node on atlas, globe or blutmagie can you please provide fingerprint and IP address again? So I may ignore it on my relays and talk to some people about it? - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT1jXjAAoJEIN/pSyBJlsRjqgIAIFxHcypU6KUaNdSvESADilM kFiitf00f4Uy9tBwSLVPQw+I2L1EmMiCNvqG4RRjV2+/PS696HCz0Jt0gVaGlMPl DHQSHsozx3BaXi5PpGeLl7uSNLHlEdytytZ8xb08I4IuqcNNHzvxnou7gXapeezC PuSABsxVLpDn+OP7QLRy/PlL948Yfgbxwb9dcn+lUdgDlByxxhMmOrk+o/VdGfnh cL/C+qgpuJiI/wrQridtBmxU8h7Z6TKKua7eWONyg6MrnjwWuZTumhAGO2H4X1Na IZiCmhEwtxb97TMG0EvgcZTeRzfzoddTnOe6ZEsiqOZ7qPNjFJ2i8RoSOI3gUCQ= =t3Mb -END PGP SIGNATURE- -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Abnormally Large Tor node accepting only Bitcoin traffic
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/28/2014 5:08 PM, Gregory Maxwell wrote: On Mon, Jul 28, 2014 at 5:31 AM, Robert McKay rob...@mckay.com wrote: I don't think Sybil attack is the right term for this.. there is only one IP address.. one identity. The bitcoin protocol is more or less identityless. It's using up lots of network capacity, number of sockets is as pretty close as you get. I'm not even sure that this behaviour can be considered abuse.. it's pretty much following the rules and maybe even improving the transaction and block propagation. It isn't relaying transactions or blocks as far as anyone with a connection to it can tell. and sure, probably not much to worry about— people have been running spy nodes for a long time, at least that much is not new. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development gmaxwell - I wanted to ask you a non-expert question. Let's say I use my bitcoin-qt on my laptop with Tor, and send some BTC or receive some, what can my Tor exit node see / do / harm? He can alter the content, by modifying and transmitting invalid transactions to the network but this will have no effect on me, e.g. can't steal coins or send them on my behalf or intercept my payments, right? It's not clear for me what data would such a node see? Why would you spend money to setup a spy node for this what relevant data can it give you? - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJT1nafAAoJEIN/pSyBJlsR8GYIAL9LkZvPbKjJ6cUxlC4yRKay YUumAafCKYMvp8Ywvz3CWpC4Gncn+v29hhJu/Nc0wSItAnf4suwrAFtBAwAYlUx8 a1J6S1hgGXCBWDZcGHDc1Xt2lLzvijDcilSZfQWXnAdoEaZyln/7Kn+o/fFcXG6h DUkSCSe9M3tN/tZBcZrhBXTENhoJ6MZldcgey6Ky0qLkmI3GCd0MhM+D15xl1LkT 6IS2r2y0RUOxkbg/SuSzFS8vnNTTWmZpbECo3Qq98W41X0M3ZtjOlaByPZXFX5K9 +HUeiptV9zukSdIRcuGH1PUQvU9nk+G1rFKr0dXu4oPvAUxqyw9uCTFgHXczuQY= =gw3W -END PGP SIGNATURE- -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
