Re: [Bitcoin-development] Possible Solution To SM Attack
On 5 November 2013 20:51, c...@safe-mail.net wrote: Possible Solution: If N amount of blocks built of the same previous block are received within a time frame of T mine on the block with the lowest hash. Logic: In order for Alice to pull of this attack she not only has to propagate her blocks first she must also ensure her blocks are of the smallest hash. Alice would now have to decrease her target to pull of this attack. Since she has a lower target it will take her longer to find a valid block negating her time advantage. If I understand the issue properly, this seems like a pretty elegant solution: if two blocks are broadcast within a certain period of eachother, chose the lower target. That's a provable fair way of randomly choosing the winning block and would seem like a pretty simply patch. Drak -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Possible Solution To SM Attack
On 5 November 2013 22:07, Quinn Harris btc...@quinnharris.me wrote: I don't think choosing the block with the lowest hash is the best option. The good and bad miners have an equal probability of finding a lower hash. But after Alice finds a block she can easily determine the probability that someone else will find a lower hash value that meets the difficulty requirement. This can be used to judge if its best to start working on the next block or work on finding a lower value hash to increase the chance her block is used. Well in that case, you could make it unpredictable by choosing based on a hash of the blockhash and chose the lowest from two. There is no way for Alice to know if Bob's resulting hash will be higher or lower than hers since she does not know Bob's blockhash in advance and therefore she would be better broadcasting her block immediately. You could even add another unpredictable factor: deciding the rules of whether higher or lower wins by hashing both competing blockhashes. If the leading two hex digits are below 128 lower wins, and if above, higher wins. Drak -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Possible Solution To SM Attack
On 5 November 2013 23:06, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Nov 5, 2013 at 2:15 PM, Drak d...@zikula.org wrote: If I understand the issue properly, this seems like a pretty elegant solution: if two blocks are broadcast within a certain period of eachother, chose the lower target. That's a provable fair way of randomly choosing the winning block and would seem like a pretty simply patch. uh. and so when my solution is, by chance, unusually low... I am incentivized to hurry up and release my block because? Yes, I saw the flaw as pointed out by Quinn so I then suggested two step solution: 1. Decide high or low by taking a the leading bytes from hash(alice)+hash(bob): above certain number we the rule is higher wins, below a certain number the lower hash wins 2. Chose winner based on the higher or lower of hash(alice) or hash(bob) based on the rule coming from 1 Now you have a situation where you don't know the rules of the game in advance (whether high or low wins) until the hands are already dealt nor have any idea about how high or low Bob's hash will be since it's not based on target anymore, but on a hash of the blockhash so it makes it a guessing game. You might have an unusually high or low hash, but then you have no idea whether higher or lower is going to win. So it is better for Alice to just broadcast the block. What do you think? Drak -- November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 14 November 2013 22:00, Alan Reiner etothe...@gmail.com wrote: Just keep in mind it will be a little awkward that 54.3 uBTC is the smallest unit that can be transferred [easily] and the standard fees are 500 uBTC.It's not a deal breaker, The fed was reduced to 0.0001/kb a while back... Drak -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 14 November 2013 22:32, Drak d...@zikula.org wrote: On 14 November 2013 22:00, Alan Reiner etothe...@gmail.com wrote: Just keep in mind it will be a little awkward that 54.3 uBTC is the smallest unit that can be transferred [easily] and the standard fees are 500 uBTC.It's not a deal breaker, The fed was reduced to 0.0001/kb a while back... Hrm. Freudian slip... you know what I mean *fee, not fed :-) so in response to those saying the fees are $0.20, actually it's more like $0.042 at current prices. Drak -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 14 November 2013 23:01, Luke-Jr l...@dashjr.org wrote: I wonder if it might make sense to bundle some other terminology fixups at the same time. A very good idea. Right now, Bitcoin-Qt has been using the term confirmations (plural) to refer to how many blocks deep a transaction is buried. We also use the term confirmation to refer to the point where a transaction is accepted as paid. IMO, the latter use makes sense, but the former leads to confusion especially in light of scamcoins which abuse this confusion to claim they have faster confirmations, implying that the actual confirmation occurs faster when it really doesn't. 5 blocks deep may not be more clear to laymen, but at least it makes it harder for people to confuse with actual confirmation. I think people are more familiar with check clearance - the payment/check has cleared. If confirmation and n confirmations together are problematic, I'd talk about cleared payments and n confirmations So a payment clears after one confirmation, but you might want to wait until the payment has been confirmed n times. Then at least you are not using the same word for two different meanings and you're using stuff more familiar in popular lexicon. I dont think it's helpful for users if we use the word blocks. Without the technical details, I just explain to normal bitcoin users that the Bitcoin network checks and confirms the payment is valid (multiple times). I think we all know the problems with the term address. People naturally compare it to postal addresses, email addresses, etc, which operate fundamentally different. I suggest that we switch to using invoice id to refer to what is now known as addresses, as that seems to get the more natural understanding to people. On the other hand, with the advent of the payment protocol, perhaps address/invoice id use will die out soon? I think key id is a bit alien at user level - it's not something they are used to. For years, people had a problem with email address, instead using email number but they got there eventually. Most people nowadays use email address So payment address or bitcoin address make better sense here when qualified as a foo address and not just an address You could also call it payment id, but I dont think invoice id since no-one pays to an invoice id that's just a reference for a payment, not the destination. People are very familiar with Paypal these days, and are familiar with paypal address or their paypal id so again I think valid contenders are bitcoin address or bitcoin id. Regards, Drak -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
On 16 November 2013 01:10, Luke-Jr l...@dashjr.org wrote: On Saturday, November 16, 2013 12:41:56 AM Drak wrote: So a payment clears after one confirmation, but you might want to wait until the payment has been confirmed n times. Then at least you are not using the same word for two different meanings and you're using stuff more familiar in popular lexicon. I dont think it's helpful for users if we use the word blocks. Confirmations in a numeric context isn't correct, though. We're using to it because we've been using Bitcoin so long, but to the average person they would expect it to mean something more than it is. If not referring to blocks, then perhaps witnessed N times? If you are talking about user interface, I don't think you have to be technically correct. It must make sense to the user. A user cares about his balance, and did a payment go through, and did my payment arrive/clear. The UI is for their benefit. For years, people had a problem with email address, instead using email number but they got there eventually. Most people nowadays use email address So payment address or bitcoin address make better sense here when qualified as a foo address and not just an address You could also call it payment id, but I dont think invoice id since no-one pays to an invoice id that's just a reference for a payment, not the destination. People are very familiar with Paypal these days, and are familiar with paypal address or their paypal id so again I think valid contenders are bitcoin address or bitcoin id. I think you might be demonstrating my point with regard to user confusion here. Bitcoin addresses are *not* like email addresses, paypal ids, etc. Bitcoin addresses aren't the destination - they're point to a destination (an account in a wallet), but they also represent information such as who is paying and what for - in other words, a specific invoice. Maybe, but again from the user's perspective they pay someone, and they receive money - just like you do with paypal using an email address. The technical bits in the middle dont matter to the user and trying to crap stuff in to be technically correct is just confusing to them. The UI needs to be about the user and fit with his experience of the world. Drak -- DreamFactory - Open Source REST JSON Services for HTML5 Native Apps OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access Free app hosting. Or install the open source package on any LAMP server. Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native! http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On 19 November 2013 16:32, Wladimir laa...@gmail.com wrote: On Mon, Oct 21, 2013 at 4:30 PM, Jeff Garzik jgar...@bitpay.com wrote: BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and are not automatically assigned a BIPS number. Are we going to move ahead with this? If so, I'm volunteering to create the repository and import the current BIPs from the wiki there (and convert from wiki markup to markdown where necessary). 2) Time passes. Software for BIP drafts is developed, tested, published, and publicly discussed in a typical open source manner. Personally I think it is useful to have a number as soon as a BIP can be implemented, even if still in draft status; it gives something to refer to when mentioning a certain improvement proposal (in commit messages and such it could be called BIP xxx Draft). I don't think we are at risk of running out of numbers to assign any time soon. It's quite normal for standards bodies to allocate numbers when in draft status. If they don't pass, they don't pass - they are clearly labelled DRAFTs. +1 on having things in a github repository. Much better for collaboration, Drak -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On 19 November 2013 17:01, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Nov 19, 2013 at 8:53 AM, Drak d...@zikula.org wrote: It's quite normal for standards bodies to allocate numbers when in draft status. If they don't pass, they don't pass - they are clearly labelled DRAFTs. +1 on having things in a github repository. Much better for collaboration, The IETF makes a clear distinction between individual proposals and documents which have been accepted by a working group. The former are named after their authors. Work is not assigned a number until it is complete. I believe it is important to distinguish complete work that people should be implementing from things which are incomplete, and even more important to distinguish the work of single parties. Otherwise you're going to get crap like BIP90: Increase the supply of Bitcoins to 210 million being confused as an earnest proposal supported by many that has traction. I wasnt suggesting people add drafts willy nilly to the repository. When working on a proposal you can work on it in your own fork and create a PR. When it's ready to be accepted as a working draft by the WG, then it can be merged into the draft folder. At which point, PRs are made to that draft copy until it gets into a ready state to become final. If passed, it's moved to the accepted/ folder. This way random BIPS cannot be added to the drafts/ folder in the official repo. They are only added once they are accepted as a working draft proposal by Gavin or whatever. Now you get all the niceties of github workflow for collaboration and tweaking of the draft proposal. Drak -- Shape the Mobile Experience: Free Subscription Software experts and developers: Be at the forefront of tech innovation. Intel(R) Software Adrenaline delivers strategic insight and game-changing conversations that shape the rapidly evolving mobile landscape. Sign up now. http://pubads.g.doubleclick.net/gampad/clk?id=63431311iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Floating fees and SPV clients
I dont like the idea of putting the min fee in the hands of the receiver. Seems like that will work against the best interests of senders in the long run. Why not try a different path of calculating the min fee like difficulty retarget. You can analyse the last 2016 blocks to find the average fee accepted per kb (which would include transactions that were included without fees) and then write that into the block as a soft recommendation that wallets could use in the UI. This way the price can vary up and down according to what people were willing to spend on fees and miners willing to accept. I absolutely do not trust vendors to set fees. I think it has to be based on what senders are willing to pay and what miners are willing to accept. Drak -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Floating fees and SPV clients
On 3 December 2013 11:46, Mike Hearn m...@plan99.net wrote: On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen gavinandre...@gmail.comwrote: If users want to pay with a huge transaction then it seems to me the user should cover that cost. Allowing users to pay merchants with 100K transactions full of dust and expecting them to eat the cost seems like a great way to enable bleed-the-merchant-dry attacks. A merchant can always refuse the payment and refund it if that's a practical problem. I doubt it would be though. If a user is trying to buy something from the merchant, they will want it to work, and it'll be up to the developers of the wallet they're using to ensure it never does anything obnoxious or unacceptable that would result in people hating to receive money from that app. Refunds in this circumstance would be problematic because someone is going to lose because they have to pay the fee. If the sender's money is refunded minus the fee, they will be unhappy. And the merchant will be unhappy about having had an unacceptable transaction they have to send back, and eat a fee for the privilege. This kind of situation needs to be avoided at all costs. -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349351iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
There is really no excuse for not using an SSL certificate. Without one it
would be trivial for an attacker to change the contents of the page via
MITM.
Recent studies have shown MASSIVE abuse of the BGP routing protocol being
used to redirect websites through a third party.
This is not a theoretical attack, it's happening every single day on a
global scale and could be used to divert users to a rogue versions of
software.
It's just a matter of time... it will happen sooner or later given the
incentives it could bring...
Recent references:
http://www.theregister.co.uk/2013/11/22/net_traffic_redirection_attacks/
http://www.wired.com/threatlevel/2013/12/bgp-hijacking-belarus-iceland/
The only way to mitigate these MITMs is to use SSL.
Also it's about time we hosted the Bitcoin Qt software at Github. They have
a releases feature where you can upload a packaged release (see
https://github.com/blog/1547-release-your-software). There are also no
adverts (another privacy leak at the least) and many feel are more
trustworthy than Sourceforge: it also makes sense to have the downloads
where the source is developed.
Regards,
Drak
On 8 December 2013 03:38, Odinn Cyberguerrilla
odinn.cyberguerri...@riseup.net wrote:
Hello, re. the dedicated server for bitcoin.org idea, I have a few
thoughts
1) I have commented in a blogpost of August 2013 at
https://odinn.cyberguerrilla.org/ with some thoughts relative to possible
issues with CA related to bitcoin.org - where I mentioned something
relative to the DigiCert certificate,
DigiCert “may revoke a Certificate, without notice, for the reasons
stated in the CPS, including if DigiCert reasonably believes that” (…)
“Applicant is added to a government list of prohibited persons or entities
or is operating from a prohibited destination under the laws of the United
States” (…) “the Private Key associated with a Certificate was disclosed
or Compromised”
In the same post I mentioned
Bitcoin.org has no certificate, no encryption — a situation which has its
own obvious problems. Bitcoin.org currently sends users to download the
bitcoin-qt client from sourceforge. Sourceforge is encrypted and has a
certificate based on GeoTrust:
https://www.geotrust.com/resources/repository/legal/;
(Currently (Dec. 7, 2013) bitcoin.org shows as 'not verified' and 'not
encrypted' examining it in a cursory fashion w/ Chrome)
Not sure how this would work, but it would be nice to see the content at
bitcoin.org encrypted, of course, but also further decentralized? how many
mirrors are there of bitcoin.org - not sure, but a few things that come to
mind when thinking of this are Tahoe-LAFS and also .bit stuff (namecoin).
There are many ways to decentralize something but that is just something
that comes to mind.
This has been discussed at https://bitcointalk.org/index.php?topic=16312.0
('Is Bitcoin.org a weakness of bitcoin?) in the past and see also this
https://bitcointalk.org/index.php?topic=119652.0 which discusses mirroring
of certain content
Some things to think about.
I would like to know what are your thoughts on moving bitcoin.org on a
dedicated server with a SSL certificate?
I am considering the idea more seriously, but I'd like some feedback
before taking steps.
Saïvann
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 8 December 2013 20:40, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Dec 8, 2013 at 12:28 PM, Mike Hearn m...@plan99.net wrote: Right now I think Sirius still owns DNS for bitcoin.org which is nonsense. He needs to pass it on to someone who is actually still involved with the project. Again, the most obvious neutral candidate would be the Foundation. I am opposed to Bitcoin Foundation having control of Bitcoin.org, and I think it would be foolish of the foundation to accept it were it offered. What do you suggest though? We will need to trust someone (even in a group each person can act autonomously). The only thing I can suggest would be to hand the keys to the bitcoin project lead. Otherwise, who has admin rights to the code projects (github/sourceforge/this mailing list)? Those people have proven they can be trusted so far. Drak -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 8 December 2013 21:01, Luke-Jr l...@dashjr.org wrote: On Sunday, December 08, 2013 8:51:07 PM Drak wrote: Otherwise, who has admin rights to the code projects (github/sourceforge/this mailing list)? Those people have proven they can be trusted so far. Can someone explain how Sirius has proven the least bit untrustworthy? It's not just about trust, there is the robustness factor: what if he becomes sick, unavailable, hit by a bus? Others need the ability to pickup and run with it. The control over the domain (including ability to renew registration, alter nameservers) needs to be with more than one person. That's why I suggest using the same people who have control over the software project at sf,github. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.8.6 release candidate 1
On 9 December 2013 13:52, Roy Badami r...@gnomon.org.uk wrote: On Mon, Dec 09, 2013 at 01:39:51PM +, Drak wrote: Someone needs to update the bitcoin.org website, it still points downloads to 0.8.5 Perhaps because 0.8.6 hasn't been released yet? Or did I miss the announcement? I think it makes sense that release candidates are not promoted on bitcoin.org. It was released and it's all over bitcointalk/reddit -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fees UI warning
Not sure if this is the right place, but since a few wallet authors congregate here I though it might be the best place. It seems every once in a while you see stories of people accidentally paying huge fees. Today I read about a man who paid a 20.14BTC fee for a 0.05 BTC transaction[1], oops. There was another recently where someone paid a fee of about 200BTC which fortunately the pool operator refunded. It just occurs to me this kind of sad story could be averted if wallets implemented a confirmation box if the fee amount seems crazy - for example, if it's 10x what the default fee should be, or if it's greater than x% of the sending amount. the fee seems unusually high, are you really sure you want to pay X in fees? I realise the exact details of this might need to be fleshed out given we want flexible fees, but it should be pretty simple to agree with what looks like an unusually large fee according to the going rate. Drak [1] http://www.reddit.com/r/Bitcoin/comments/1syu3h/i_lost_all_my_bitcoins_in_an_erroneous/ -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] DarkWallet Best Practices
On 19 December 2013 13:17, Peter Todd p...@petertodd.org wrote: ** Fees Wallets MUST give users the ability to set the fee per KB they are willing to pay for their transactions. Wallets SHOULD allow users to change that fee after the fact via transction replacement. Can you add a part about SHOULD/MUST warn users if the fee is unusually high to avoid sob-stories of people sending 20BTC fees with for the 0.002BTC sandwich. Sourcecode MUST be PGP signed on a regular basis. Releases MUST be signed - in git this is accomplished by signing the release tag. Individual commits SHOULD be signed, particularly if source-code used in SHOULD be cryptographically signed I assume. ** SSL/Certificate authorties While certificate authorities are notoriously bad at the job they are supposed to be doing the CA system is still better than nothing - use it where appropriate. For instance if you have a website advertising your software, use https rather than http. Once could make efforts to publish (maybe even as signed commits in the git repo etc the current valid certificate fingerprints and which CA signed it). This would go some way to exposing MITM either by CA or in workplaces where browsers are loaded with bogus CAs for the purpose of deep packet inspection. ** Multi-factor spend authorization, AKA multisig wallets mainly discussed at the conference in terms of multiple individuals controlling funds, which is out of scope for this document Assuming any individual device is uncompromised is risky; wallet software SHOULD support some form of multi-factor protection of some or all wallet funds. Note that this is a weak should; mainly we want to According to RFC 2119 http://www.ietf.org/rfc/rfc2119.txt language, you might be better using the word RECOMMENDED or MAY over SHOULD here. Additionally, at the beginning of the spec I would put : The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119http://www.ietf.org/rfc/rfc2119.txt . Regards Drak -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [unSYSTEM] DarkWallet Best Practices
On 19 December 2013 16:04, Amir Taaki gen...@riseup.net wrote: About signing each commit, Linus advises against it: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html Yeah, it makes no sense after reading it. Nice catch. However, his recommendation for signing tags with `git tag -s` should probably be incorporated into the spec as a MUST. Drak -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
Has anyone seen the talk at 30c3 on the current NSA capabilities? https://www.youtube.com/watch?v=b0w36GAyZIA Specifically they are able to beat the speed of light between you and a website such that if you communicate with Bob, they can sent competing packets that will arrive before Bob's packets. They have realtime deep packet insertion able to inject arbitrary data into an TCP streams and can change file downloads **on the fly**. This can be done remotely. Sourceforge do not have https downloads, so this is yet another reason to move downloads to somewhere that does - like github. The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. Revealed as part of the presentation is the fact that if the NSA has access to these capabilities, then so do others and in fact one of the things revealed yesterday was independently discovered already and published. Same goes for the bitcoin.org site - why are we dragging our feet on installing an SSL certificate and redirecting all http to https? While no solution is perfect, it's a lot better than zero defense. You can see the irony of disseminating the bitcoin crypto-currency client in the clear. For anyone who has not seen the video. You will be shocked by what is actually in the wild being used today. It goes way beyond anything imaginable even in science fiction. https://www.youtube.com/watch?v=b0w36GAyZIA Drak -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?
On 3 January 2014 05:45, Troy Benjegerdes ho...@hozed.org wrote: On Tue, Dec 31, 2013 at 05:48:06AM -0800, Gregory Maxwell wrote: On Tue, Dec 31, 2013 at 5:39 AM, Drak d...@zikula.org wrote: The NSA has the ability, right now to change every download of bitcoin-qt, on the fly and the only cure is encryption. No, the only cure is the check the hashes. We should know something about hashes here. TLS is a big pile of 'too big to audit'. Spend a couple of satoshis and put the hash of the source tar.gz and the binaries in the blockchain. Problem solved. Which is why, as pointed out several times at 30c3 by several renowned figures, why cryptography has remained squarely outside of mainstream use. It needs to just work and until you can trust the connection and what the end point sends you, automatically, it's a big fail and the attack vectors are many. sarcasmI can just see my mother or grandma manually checking the hash of a download... /sarcasm Drak -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
Sorry this is possibly OT, but someone posted this thread to r/bitcoin and it's gone straight to position 1. People are really enthusiastic about this feature. Drak -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
On 16 January 2014 00:05, Jeremy Spilman jer...@taplink.co wrote: Might I propose reusable address. I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'. The problem is all addresses are reusable and to an average user, addresses are already reusable so there is little to distinguish the address format. It might be better to call it a public address in common terminology. Drak -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
Peter I agree with you about reusable addresses, but aren't we also trying to get away from the word address entirely? How about calling it a payment key or reusable payment key instead? using stealth is just asking for bad press imo. On 16 January 2014 21:28, Peter Todd p...@petertodd.org wrote: On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote: Might I propose reusable address. I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'. It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly adopted. I'm very against the name reusable addresses and strongly belive we should stick with the name stealth addresses. You gotta look at it from the perspective of a user; lets take standard pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many times as I want and everything works just great. I also can enter the address on blockchain.info's search box, and every transaction related to the address, and the balance of it, pops up immediately. What is that telling me? A: Addresses starting with 1 are reusable. B: Transactions associated with them appear to be public knowledge. Now I upgrade my wallet software and it says I now have a reusable address. My reaction is Huh? Normal addresses are reusable, what's special about this weird reusable address thing that my buddy Bob's wallet software couldn't pay. I might even try to enter in a reusable address in blockchain.info, which won't work, and I'll just figure must be some new unsupported thing and move on with my life. On the other hand, suppose my wallet says I now have stealth address support. I'm going to think Huh, stealth? I guess that means privacy right? I like privacy. If I try searching for a stealth address on blockchain.info, when it doesn't work I might think twig on Oh right! It said stealth addresses are private, so maybe the transactions are hidden? I might also think Maybe this is like stealth/incognito mode in my browser? So like, there's no history being kept for others to see? Regardless, I'm going to be thinking well I hear scary stuff about Bitcoin privacy, and this stealth thing sounds like it's gonna help, so I should learn more about that Finally keep in mind that stealth addresses have had a tonne of very fast, and very wide reaching PR. The name is in the public conciousness already, and trying to change it now just because of vague bad associations is going to throw away the momentum of that good PR and slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I based on conversations there with people there, technical and non-technical, almost everyone had heard about them and almost everyone seemed to understand the basic idea of why they were a good thing. That just wouldn't have happened with a name that tried to hide what stealth addresses were for, and by changing the name now we risk people not making the connection when wallet software gets upgraded to support them. -- 'peter'[:-1]@petertodd.org 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740 -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Stealth Addresses
That could also work. Still, didn't we want to ditch the word address? Could be a privacy key... On 17 Jan 2014 09:15, Mike Hearn m...@plan99.net wrote: I must say, this shed is mighty fine looking. It'd be a great place to store our bikes. But, what colour should we paint it? How about we split the difference and go with privacy address? As Peter notes, that's what people actually like and want. The problem with stealth is it's got strong connotations with American military hardware and perhaps thieves sneaking around in the night: https://www.google.com/search?tbm=ischq=stealth But everyone loves privacy. On Fri, Jan 17, 2014 at 8:49 AM, Drak d...@zikula.org wrote: Peter I agree with you about reusable addresses, but aren't we also trying to get away from the word address entirely? How about calling it a payment key or reusable payment key instead? using stealth is just asking for bad press imo. On 16 January 2014 21:28, Peter Todd p...@petertodd.org wrote: On Wed, Jan 15, 2014 at 04:05:27PM -0800, Jeremy Spilman wrote: Might I propose reusable address. I think that describes it best to any non-programmer, and even more so encourages wallets to present options as 'one time use' vs 'reusable'. It definitely packs a marketing punch which could help drive adoption. The feature is only useful if/when broadly adopted. I'm very against the name reusable addresses and strongly belive we should stick with the name stealth addresses. You gotta look at it from the perspective of a user; lets take standard pay-to-pubkey-hash addresses: I can tell my wallet to pay one as many times as I want and everything works just great. I also can enter the address on blockchain.info's search box, and every transaction related to the address, and the balance of it, pops up immediately. What is that telling me? A: Addresses starting with 1 are reusable. B: Transactions associated with them appear to be public knowledge. Now I upgrade my wallet software and it says I now have a reusable address. My reaction is Huh? Normal addresses are reusable, what's special about this weird reusable address thing that my buddy Bob's wallet software couldn't pay. I might even try to enter in a reusable address in blockchain.info, which won't work, and I'll just figure must be some new unsupported thing and move on with my life. On the other hand, suppose my wallet says I now have stealth address support. I'm going to think Huh, stealth? I guess that means privacy right? I like privacy. If I try searching for a stealth address on blockchain.info, when it doesn't work I might think twig on Oh right! It said stealth addresses are private, so maybe the transactions are hidden? I might also think Maybe this is like stealth/incognito mode in my browser? So like, there's no history being kept for others to see? Regardless, I'm going to be thinking well I hear scary stuff about Bitcoin privacy, and this stealth thing sounds like it's gonna help, so I should learn more about that Finally keep in mind that stealth addresses have had a tonne of very fast, and very wide reaching PR. The name is in the public conciousness already, and trying to change it now just because of vague bad associations is going to throw away the momentum of that good PR and slow down adoption. Last night I was at the Toronto Bitcoin Meetup and I based on conversations there with people there, technical and non-technical, almost everyone had heard about them and almost everyone seemed to understand the basic idea of why they were a good thing. That just wouldn't have happened with a name that tried to hide what stealth addresses were for, and by changing the name now we risk people not making the connection when wallet software gets upgraded to support them. -- 'peter'[:-1]@petertodd.org 0001b0e0ae7ef97681ad77188030b6c791aef304947e6f524740 -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk ___ Bitcoin-development
[Bitcoin-development] MtGox blames bitcoin
What is the official response from the Bitcoin Core developers about MtGox's assertion that their problems are due to a fault of bitcoin, as opposed to a fault of their own? The technical analysis preluding this mess, was that MtGox was at fault for their faulty wallet implementation. Drak -- Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] MtGox blames bitcoin
Well done Gavin for quickly setting the record straight[1] officially as project lead. MtGox tried to blame their issues by throwing Bitcoin under a bus and I am glad there has been a public rebuttal showing up their incompetence which is doing harm to the bitcoin eco system. Basically, yes there are issues, but MtGox should have worked around it. Also thanks to Gregory for also writing[2] about the matter. Drak [1] https://bitcoinfoundation.org/blog/?p=418 [2] http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/ -- Androidtrade; apps run on BlackBerryreg;10 Introducing the new BlackBerry 10.2.1 Runtime for Android apps. Now with support for Jelly Bean, Bluetooth, Mapview and more. Get your Android app in front of a whole new audience. Start now. http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Extension for BIP-0070 to support recurring payments
Forgive me if I missed it, but the spec doesnt look like it can handle only
handle periods of per week, per month, per quarter rather than 'n period'.
I take Paypal as a reference example for subscription payments where you
can set recurring to every: n days, n weeks, n months, n years. That way a
quarterly payment is every 3 months. This fine granularity is necessary
because sometime a payment scheme can be per 4 weekly rather than per
monthly.
So in summary the spec needs daily as an option, and to specify the
recurring cycle as every n*period (one of daily, weekly, monthly, yearly):
and you can drop quarterly since it's just expressed as per 3*monthly.
Drak
On 25 February 2014 16:29, Mike Hearn m...@plan99.net wrote:
Hey there,
So the essence of this protocol is as follows:
enum PaymentFrequencyType {
WEEKLY = 1;
MONTHLY = 2;
QUARTERLY = 3;
ANNUAL = 4;
}
message RecurringPaymentDetails {
// Namespace for the merchant such as org.foo.bar
required string merchant_id = 1;
// Id for the recurring subscription
required bytes subscription_id = 2;
// Contracts associated with a given subscription
repeated RecurringPaymentContract contracts = 3;
}
message RecurringPaymentContract {
// Unique id for a given contract
required bytes contract_id = 1;
// URL to poll to get the next PaymentRequest
required string polling_url = 2;
// Timestamp; when this contract starts
required uint64 starts = 3;
// Timestamp; when this contract should be considered invalid
optional uint64 ends = 4;
// Expected payment frequency
optional PaymentFrequencyType payment_frequency_type = 5;
// Max payment amount within that frequency (e.g. no more than 5 BTC
per month)
optional uint64 max_payment_per_period = 6;
// Max payment amount (e.g. no more than 3 BTC per payment)
optional uint64 max_payment_amount = 7;
}
I have the following comments:
1. There's no need to serialize RecurringPaymentDetails as bytes here.
It's done that way outside of PaymentDetails in order to support digital
signatures over protobufs that may have extensions the wallet app isn't
aware of, but it's a pain and inside PaymentDetails (and therefore for most
extensions) it shouldn't be necessary. So you can just use optional
RecurringPamentDetails recurring_payments = 8;
2. There's only 4 possibilities here for recurrences. That seems
rather restrictive. Is the cost of being more expressive really so high?
Why not allow more flexible specification of periods?
3. If there's no payment_frequency_type field then what happens? A
quirk of protobufs to be aware of is that making an enum field required
can hurt backwards compatibility. Because it will be expressed using a
languages underlying enum type, if there's a new enum member added later
old software that attempts to deserialize this will throw exceptions
because the new unknown member would be unrepresentable in the old model.
Making the field optional avoids this problem (it will be treated as
missing instead) but means software needs to be written to know what to do
when it can't read the enum value / sees enum values from the future.
4. I assume the amounts are specified in terms of satoshi, and
timestamps are UNIX time, but better to make that explicit.
5. Seems there's an implicit value constraint that max_payment_amount
= max_payment_per_period. What happens if that constraint is violated?
Best to document that.
6. What's the merchant ID namespace thing about? What's it for? What
happens if I set my competitors merchant ID there?
7. What's the subscription ID? Is this stuff not
duplicative/redundant with the existing merchant_data field?
8. In what situations would you have 1 contract per payment request?
I'm not sure I understand why it's repeated. Presumably if there are zero
contracts included the data should be ignored, or an error thrown and the
entire payment request rejected? Which should it be?
9. It's unclear to me given such a contract when the payment should
actually occur. For instance if it's monthly then what day in the month
would the payment occur?
10. You'll notice I moved the comments to be above the field
definitions. I know the current proto isn't done that way, but let's change
it - long comments are good and putting them above the field definitions
encourages people to write enough detail without being put off by line
length constraints
I think the next step would be to talk to BitPay/get Jeff+Stephen involved
because I know they have customers that really want recurring payments, and
those guys will have a clearer idea of customer requirements than we do. I
feel
Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release
On 28 February 2014 14:42, Warren Togami Jr. wtog...@gmail.com wrote: https://github.com/litecoin-project/litecoin/commit/db4d8e21d99551bef4c807aa1534a074e4b7964d In one way in particular, the transaction fees per kilobyte completely failed to account for the actual cost to the network. If Bitcoin had adopted a common-sense rule like this, I would have had no reason to join Litecoin development last year. This is one of the few economic design flaws that Satoshi overlooked in the original design. Is there any particular reason that patch would not make it into bitcoin if submitted? Drak -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Payment Protocol Hash Comments
Not true, PHP does support sha2 http://php.net/manual/en/mhash.constants.php http://php.net/manual/en/function.hash-algos.php#refsect1-function.hash-algos-examples On 2 Mar 2014 08:44, Mike Hearn m...@plan99.net wrote: SHA-1 support is there for PHP developers. Apparently it can't do SHA-2. On 2 Mar 2014 08:53, Jeremy Spilman jer...@taplink.co wrote: From BIP70: If pki_type is x509+sha256, then the Payment message is hashed using the SHA256 algorithm to produce the message digest that is signed. If pki_type is x509+sha1, then the SHA1 algorithm is used. A couple minor comments; - I think it meant to say the field to be hashed is 'PaymentRequest' not 'Payment' message -- probably got renamed at some point and this is an old reference calling it by its original name. - Could be a bit more explicit about the hashing, e.g. 'copy the PaymentRequest, set the signature field to the empty string, serialize to a byte[] and hash. - SHA1 is retiring, any particular reason to even have it in there at all? - Should there any way for the end-user to see details like the pki_type and the certificate chain, like browser do? Thanks, Jeremy -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer Customize your own dashboards, set traffic alerts and generate reports. Network behavioral analysis security monitoring. All-in-one tool. http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Multisign payment protocol?
I was wondering if there would be merit in a kind of BIP for a payment protocol using multisig? Currently, setting up a multisig is quite a feat. Users have to exchange public keys, work out how to get the public keys from their addresses. If one of the parties are not savvy enough, an malicious party could easily be setup that was 2 of 3 instead of 2 of 2 where the malicious party generates the multisig address+script and thus be able to run off with funds anyway. It's also terribly complex to generate and keep track of. There's been a nice attempt at creating an browser interface at coinb.in/multisig but it still lacks the kind of ease with created by the payment protocol. If there was a BIP then it would go a long way to aiding future usability of multisig wallet implementations. What are your thoughts? Drak -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Multisign payment protocol?
Gavin, You have pretty much nailed my intent in both respects. This sets up a way to negotiate the address and abstract away the nasty details of finding public keys from bitcoin addresses, and provides a nice clean way for redemption abstracting away the long strings of hex. For redemption, I think as each party signs the tx if the script returns true, it would be acceptable to just go right ahead and broadcast it, or maybe as you suggest all signatures go back to the initiating party and they do the final work. I very much like the idea of assuming each party uses HD wallets, that certainly simplifies things greatly. I also like the use of email addresses as a negotiation medium, but I also wonder if this could be made agnostic in any BIP proposal so it could work with other communication mediums like bitmessage for example (just forward thinking anonymity a little). I definitely think there is a need for a protocol because multisig, regardless of the application has two technically involved steps: negotiation of an address, and redemption of any subsequently encumbered funds. A protocol would enable different wallet implementations to participate in such a transaction and make wide-spread use much more likely and possible. Drak On 11 March 2014 01:15, Gavin Andresen gavinandre...@gmail.com wrote: Multisig is orthogonal to the payment protocol (but payment protocol is needed first). There need to be protocols for: a) Establishing multisig wallets of various sorts. See: https://moqups.com/gavinandresen/no8mzUDB/ https://moqups.com/gavinandresen/no8mzUDB/p:ab18547e0 ... etc. for a UI mock-up. There needs to be some protocol so all participants in a multisig wallet contribute keys (actually, we should just assume everybody uses BIP32 HD public keys so we get privacy from the start). Multi-person shared wallets, escrows, and wallet protection service wallets (which might be protected with two-factor authentication) are different use cases and probably use slightly different protocols (and will probably need different BIPs eventually). b) Gathering signatures for a multisig spend. Here is where the payment protocol is useful; the PaymentRequest message should be passed around so all participants know what is being paid for, and maybe a partially-signed Payment message is where the signatures are gathered (or maybe the signatures are sent separately and one of the participants creates and submits the Payment and gets the PaymentACK... to be designed). See: https://moqups.com/gavinandresen/no8mzUDB/p:a7e81be96 https://moqups.com/gavinandresen/no8mzUDB/p:af7339204 ... for UI mock-up for the multi-person-spend case. And maybe a protocol for I don't want to be part of this multisig any more / I lost control of my private key don't trust me in this multisig any more. On Mon, Mar 10, 2014 at 8:14 PM, Jeff Garzik jgar...@bitpay.com wrote: All of that only melds with the payment protocol under an extremely expansive definition of payment. The payment protocol is really geared towards a direct one-to-one relationship -- Gavin Andresen -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] moving the default display to mbtc
I agree with you Jeff. The unit switch needs to happen once and once only, but that is exactly why I said the defaults really need to change in Bitcoin-Qt since that is still the main reference implementation and it will influence others. Bitpay could also take the lead here and make the switch to their defaults. That would greatly assist the uBTC movement. Regardless of what anyone says, Bitcoin-Qt is still the main reference implementation and the best way to encourage a change in the community at large is for the default units to be changed here. Core devs can surely garner enough consensus among themselves to accept and merge a PR to that effect. That will send a message, more than anything else that can be done. My two satoshi. Drak On 13 March 2014 16:29, Jeff Garzik jgar...@bitpay.com wrote: On Thu, Mar 13, 2014 at 12:14 PM, Alan Reiner etothe...@gmail.com wrote: Of course, as Mike said, this ship may have already sailed, but if there's any way to revisit this, I'm there. We're just about to do another Armory release and could support this very easily. mBTC now just means the issue -will- be revisited in the future. Just a question of when, not if. People and software in various nations handle big numbers for small values (e.g. Yen) just fine. People and software do -not- handle extra decimal places well, field experience shows. vendor hat: on To roll out QuickBooks support --without converting any numbers, a key financial attribute-- mBTC is simply insufficient today, not in the future. I also argue that it is a security risk, as follows: To support accounting packages limited to 2 decimal places, decimal point conversion must be performed. This produces a situation where your accounting system shows numbers that do not visually match the numbers in the bitcoin software. That, in turn, making auditing more difficult, particularly for outsiders. Shipping with mBTC defaults was decidedly unwise, considering that -- like BTC -- it fails to solve existing, known problems that uBTC can solve, and considering the inevitable mBTC-uBTC switch. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] python-bitcoinlib v0.1 release - a low-level Python2/3 interface to the Bitcoin protocol
Would it make sense to pull that stuff in and add Peter with commit access since your repo is top of the fork tree. Drak On 15 March 2014 16:47, Jeff Garzik jgar...@bitpay.com wrote: Sounds great. I'm glad to see this with a more active maintainer. Maintaining -three- client libs was a bit much for me. On Sat, Mar 15, 2014 at 9:43 AM, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I noticed that the ngccbase Colored Coin client(1) added a python-bitcoinlib dependency, specifically my fork. In addition there is also now a rudementary python-bitcoinlib package in archlinux. So with that in mind I'm releasing v0.1, perhaps somewhat arbitrarily: https://github.com/petertodd/python-bitcoinlib/tree/v0.1 This Python2/3 library provides an easy interface to the bitcoin data structures and protocol. The approach is low-level and ground up, with a focus on providing tools to manipulate the internals of how Bitcoin works in a Pythonic way, without straying far from the Bitcoin Core implementation. The current status of the library as of v0.1 is that the support for data-structures related to transactions, scripting, addresses, and keys are all quite usable and the API is probably not going to change that much. Bitcoin Core RPC support is included and automatically converts the JSON to/from Python objects when appropriate. EvalScript(), VerifyScript(), and SignatureHash() are all functional and pass all the Bitcoin Core unittests, as well as a few that are still yet to be merged.(2) You'll find some examples for signing pay2script-hash and p2sh txouts in the examples/ directory; I personally used the transaction signing functionality to make up a set of unittests related to OP_CODESEPARATOR and FindAndDelete() recently. Finally my dust-b-gone script(3) is another good example, specifically of the RPC functionality. I personally haven't had any need for the p2p network related code for some time, so I'm sure it's not in a good state and it lacks unittests; Bloom filters for one are missing the merkle-block support to actually make them useful. But the RPC support makes up for that for many uses. This release and others in the future are signed by my PGP key, as well as every publicly pushed commit. You can verify the key via WoT, my bitcointalk account, signing history in the Bitcoin Core repo, and mailing list records among other sources. Disclaimer: This is alpha code in a language not known for type-safety. I wouldn't personally use python-bitcoinlib for anything other than experiments and neither should you. 1) https://github.com/bitcoinx/ngcccbase 2) https://github.com/bitcoin/bitcoin/pull/3861 3) https://github.com/petertodd/dust-b-gone - -- 'peter'[:-1]@petertodd.org 97649e8d66395b3cb4527263409adf628c76cc56af0434fe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTJFkFXhSAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDA3OGEyNGUxNTBlNTc2ZGVjZWUyYWQzMGNhMmE2YTRhMmM3 NGVkYmJkNjM2NDViNjcvFIAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftZiwgAk8YVN9t76tKIKcWKyrGgv8yk UZGZkkrowED0lyhMXfmviezeWhjvHZgQrwha2hAuik36WEBN1jnv9wuJ6g9tnxGY PyG8n1SV2rtQ/QIJyL6wOuqL3UZi6d6IdZ/udVmyGwz+XhE89AwitR0++MvxkPNv i9R3Gw5Z1CnS2W0jGpAT88k3q3pqEzbYutP/FaylL2+6MuSUGwHUoY8dqcRkwkw1 eIrd2W33x4NvuxYPLnHR64uE0B8KoreZOyyskMdeMsKtZNflkfgfMiD10xnw2PGx z8S42wPbrI5ZYLL1OLdRfuKMdQ4qOyF4jfV+QRZWQ5t5Qh1akVWmz7ffFHGo0Q== =k1pi -END PGP SIGNATURE- -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] python-bitcoinlib v0.1 release - a low-level Python2/3 interface to the Bitcoin protocol
Yes. I think the problem is your fork has been under more development and upstream has stalled. The problem with this is it becomes unclear which repo is the main one as it really has become a fork and of course then development really does fork properly which is a shame because it doesn't nurture community contributions around the project which is really important. Drak On 15 March 2014 17:22, Peter Todd p...@petertodd.org wrote: On Sat, Mar 15, 2014 at 05:12:42PM +, Drak wrote: Would it make sense to pull that stuff in and add Peter with commit access since your repo is top of the fork tree. I've noticed it looks like people actually using my 'pythonize' code have been linking directly to my tree in things like documentation and build scripts, so the URL is probably not a problem. I did open a pull-req on the bitcoin.org repo to change that URL however: https://github.com/bitcoin/bitcoin.org/pull/346 -- 'peter'[:-1]@petertodd.org ef4a047ecc7077b7855626b9c9bf07e528e0c6ace2da30a8 -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Why are we bleeding nodes?
For what it's worth, the number of nodes rose dramatically during the China bullrun (I recall 45k in China alone) and dropped as dramatically as the price after the first PBOC announcement designed to cool down bitcoin trading in China. On 7 April 2014 12:34, Mike Hearn m...@plan99.net wrote: At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and still falling: http://getaddr.bitnodes.io/dashboard/chart/?days=60 I know all the reasons why people *might* stop running a node (uses too much disk space, bandwidth, lost interest etc). But does anyone have any idea how we might get more insight into what's really going on? It'd be convenient if the subVer contained the operating system, as then we could tell if the bleed was mostly from desktops/laptops (Windows/Mac), which would be expected, or from virtual servers (Linux), which would be more concerning. When you set up a Tor node, you can add your email address to the config file and the Tor project sends you emails from time to time about things you should know about. If we did the same, we could have a little exit survey: if your node disappears for long enough, we could email the operator and ask why they stopped. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees_APR ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Jenkins pull-tester
I would like to set up my own bitcoin pull-tester on Jenkins. Are there any instructions or guidance written anywhere? Drak -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ 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
Cut it out with the ad hominem attacks please. If you cant be civil, please go away until you learn some manners. I think the issue being discussed is do you orphan an entire block causing distress to users as well, or try to just cause distress just to the evil miner? This discussion is about exploring the ramifications of all these options. I think you are also forgetting that, miners can implement their own filters and behaviours without anyone's consent. So having an open discussion and exploring all possibilities can only be a good thing before someone goes off an implements a change without taking into account other points of view they may not have considered yet. On 23 Apr 2014 19:51, Justus Ranvier justusranv...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 06:37 PM, Mike Hearn wrote: If you want to try and argue that the development list is the wrong place to discuss development, please do so on another thread (or your blog). Let's keep this thread for discussion of the original proposal - ideally, discussed with the dryness that a topic as nerdy as distributed consensus algorithms deserves ;) Is that what you say to yourself to quiet your conscience at night (assuming you're one of the non-sociopathic humans who does indeed have one)? It's just a nerdy distributed consensus problem? The things you're talking about fucking around with have real life implications for quite a few people and your casual dismissal of this is precisely why I responded in the way that I did. What you're doing is reckless endangerment and you're not got to get away with brushing it off as a mere technical detail. Sunlight is the best disinfectant, and this episode is demonstrating to the world exactly how averse you are do that kind of transparency. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTWAsmAAoJECoisBQbQ4v0XTcIAL70+EAkSMUgvGeTN+mROkkd 3ap5NhUYehfW33gEEEyO3a6ofrb6k1a8EbHlzDyq7qPZ925kdvbnwqXDQm7auAh1 V8IPAwp+JfCgVDVAxtHuUBUvTuuCn1Mrxnf6ppwzFywBxU6l6KYK9zac1HoX3EVY QxME15zrBmtJfo9/ed9yWz8ZXl6nsx47D3r0VE8FiENJRgxLfZ7Odsr/sGvgL71N aYPv7vMxRBNXDvrMhEuYKa3L83W5kv4JJxzueUyO/0bww/aaeZMZr850u/hUjMgU ui37M+kiFHug3semWGKs1yJiKsEPsEPaU4j6WSDrd0bNbc73bBjvHm9SGYRHzDQ= =L5nX -END PGP 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 -- 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] bits: Unit of account
+1 On 4 May 2014 02:06, Chris Pacia ctpa...@gmail.com wrote: Absent a concerted effort to move to something else other than 'bits', I would be willing to bet the nomenclature moves in that direction anyway. 'Bits' is just a shorten word for 'millibits' (or microbits, if you will). It's easier to say and my guess is people would tend to use it naturally own their own. Kind of like 'bucks' for dollars. The other synergies are: -bit is part of the word Bitcoin. The currency unit bit is part of a whole bitcoin. -bit symbolically represents the tech nature of the bitcoin. -bit used to be a unit of money way back when. This largely reclaims it. -when used as money bit when in references to a precession metal coin. The name 'bitcoin' references that as well as the mimicking of the gold standard in the protocol rules. All around I don't think there is a better fit. I doubt people will get confused by it. The context it's used in will distinguish it from other uses of the word. On 05/03/2014 12:27 PM, Mike Caldwell wrote: I agree with the sentiment that most people don't understand either computer science or Bitcoin. The goal of getting people to understand enough about Bitcoin to use it is achievable and a goal that is in scope of our efforts. Getting them to understand computer science at large at the same time, less so. The fact that people routinely confuse RAM and hard drive sizes has much to do with the fact that the average lay person has little need to prioritize this as something to keep in the forefront. They don't get horribly confused, they just simply don't get worked up over what looks to them like a rounding error, much to the dismay of anyone who believes that everyone should be an expert at computer science. The average joe may assess (accurately from his perspective) that the distinction isn't important enough to merit significant mental resources and he is justified in not expending them that way even if someone else thinks he should. Poor understanding is precisely what a proper effort to name this would be to avoid. It is not frill or aesthetics, it is a planned targeting of language to achieve the clearest communication to the widest possible target audience using the language most likely to be understood by them in light of our objectives. It's marketing. Mike Sent from my iPhone On May 3, 2014, at 9:49 AM, Christophe Biocca christophe.bio...@gmail.com wrote: Context as a disambiguator works fine when the interlocutors understand the topics they're talking about. Not a day goes by without me seeing neurotypical people get horribly confused between RAM and Hard Drive sizes, because they share the same units (not that that can be helped, as the units are supposed to be the same, base 1000 vs 1024 notwithstanding). Bit (as a unit) is already really confusing for anyone who doesn't deal with it on a regular basis. I think people who don't see an issue are making an assumption based on their own lack of confusion. We understand computer science AND Bitcoin. Most people have zero understanding of either. Bitcoin already has a ton of issues with terrible names for things: - Mining (for transaction validation). - Addresses (which are meant to be one-time use, and don't even really exist at the network level). - Wallets (which don't hold your bitcoins, can be copied, and all backups can be stolen from equally). I end up having to make the distinctions obvious every time I explain Bitcoin to someone new to it. There's an acceptable tradeoff here, because there were arguably no better words to assign to these concepts (although I'd argue mining is a really awful metaphor, and is the one that prompts the most questions from people). Then add to the pile a bunch of third parties naming themselves after parts of the protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've definitiely seen average people get confused between the blockchain and blockchain.info (not so much Coinbase, because that name doesn't come up in beginner explanations). It seems downright masochistic to add yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile for no reason other than aesthetics. Are we actively trying to confuse people? -- 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] DNS seeds unstable
I am sure the failure here is probably more mundane like a a service not restarted, or not on auto restart when server is rebooted and such like. The dns seeder works pretty efficiently in my experience. Maybe we need more seeders and to include the ability for zone transfers so existing seeders can spread their records to multiple servers running standard DNS servers like bind etc. On 15 May 2014 12:50, Andreas Schildbach andr...@schildbach.de wrote: I'm bringing this issue up again. The current Bitcoin DNS seed infrastructure is unstable. I assume this is because of we're using a custom DNS implementation which is not 100% compatible. There have been bugs in the past, like a case sensitive match for the domain name. Current state (seeds taken from bitcoinj): mainnet: seed.bitcoin.sipa.beOK dnsseed.bluematt.me OK dnsseed.bitcoin.dashjr.org SERVFAIL, tried multiple ISPs seed.bitcoinstats.com OK testnet: testnet-seed.bitcoin.petertodd.org SERVFAIL, just from Telefonica testnet-seed.bluematt.meOK (but only returns one node) Note: Telefonica is one of Europe's largest ISPs. I would try to improve DNS myself, but I'm not capable of writing C. My fix would be to reimplement everything in Java -- I doubt you guys would be happy with that. -- 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 -- 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] Proposed BIP 70 extension
Seems like a nice idea.
On 24 June 2014 14:27, Mike Hearn m...@plan99.net wrote:
Coinbase have started allowing merchants to set discounts for purchasing
with Bitcoin. Seeing an individual discount is not very motivating as they
tend to be small. Seeing them stack up over time can be more motivating
because it feels like free money. Many businesses exploit this effect with
loyalty points, etc. Bitcoin should do this too - show the user how much
they're saving by using Bitcoin instead of credit cards.
I suggested to Charlie Lee (who pushed this through at Coinbase) and
Stephen Pair the following minor BIP 70 extension:
message PaymentDetails {
// Size in satoshis of any discount provided by the merchant ONLY
// because the user chose to pay using Bitcoin or other similar
// digital currency. Other kinds of discounts, loyalty bonuses and
// so on should not be recorded here, rather they could be mentioned
// in the memo field. This field exists so wallets can show the user
// a running total of how much money they have saved by avoiding
// credit cards and bank payments; the goal is to encourage people to
// use Bitcoin. Putting other kinds of discounts here would make the
// running total calculated meaningless; so don't do it!
optional uint64 currency_usage_discount_size = 8;
}
Wallets would then be able to persist this data to disk and compete on
cool visualisations for how much money you saved over time.
We haven't formalised how to extend BIP 70 yet, that's my fault. We should
do that. In the meantime, what do people think of this proposal?
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Anyone still using SOCKS4?
*watches the tumble weed blow by* I think it's pretty safe to remove it... On 4 July 2014 08:15, Wladimir laa...@gmail.com wrote: On Wed, Jun 11, 2014 at 5:39 PM, Wladimir laa...@gmail.com wrote: If no one screams fire, we plan on removing support for it in the next major release, for two reasons: - It would remove some crufty, hardly tested code paths - SOCKS5 offers better privacy as it allows DNS redirection Another one: - SOCKS5 supports IPv6 Last call... Wladimir -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft___ 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
Related to Russia's Tor bounty? http://www.theguardian.com/world/2014/jul/25/russia-research-identify-users-tor On 28 Jul 2014 04:45, Gregory Maxwell gmaxw...@gmail.com 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 -- 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] Reconsidering github
On 23 August 2014 12:38, Pieter Wuille pieter.wui...@gmail.com wrote: That allows using github as easy-access mechanism for people to contribute and inspect, while having a higher security standard for the actual changes done to master. I'd also like to point out the obvious: git uses the previous hash as part of the formula to generate the current commit hash thus tampering with history while possible would be instantly noticed because we all have copies of the repository. Tampering would be completely evident (pushes would fail for a start, and even simple merges would bork). It's just not possible to tamper with the repository without it being discovered, even with collusion (or strong arming) of github. The social benefits of github make it idea for open source projects that want community participation. The barrier to entry is low. The only weak spot of github is the releases section, but since we don't actually distribute Bitcoin from github the point is moot. I think github haters fail to see the vast benefits of a social hub like github. Their issue tracker may not be as sophisticated, it serves well and the project is extremely productive. Don't shoot yourself in the foot - a move away from github would be a disaster for the project. When you look at the attack surface of using github, it's pretty small and would not go unnoticed, thus nullifying concern. -- Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
On Wed, Oct 15, 2014 at 4:54 PM, Adam Back a...@cypherspace.org wrote: please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Please not sourceforge. * Google lists are somehow a little proprietary or gmail lockin focused eg it makes things extra hard to subscribe with a non-google address if google has any hint that your address is associated with a gmail account. Quite frustrating. Mailman is good enough... -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP process
On Sun, Oct 19, 2014 at 8:17 AM, xor x...@freenetproject.org wrote: I joined the list when Bitcoin was already in the 10-billions of market capitalization, and it actually really surprised me how low the traffic is here given the importance of Bitcoin. So as a random stranger to the project, I would vote against that if I was allowed to. There really should be *more* discussion here, and splitting the list up won't help with that. I agree. This is also where the best peer review is to be found. Splitting the list will dilute this. -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email, SMS, voice calls or mobile push notifications. Take corrective actions from your mobile device. http://p.sf.net/sfu/Zoho___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size
On Mon, Nov 17, 2014 at 11:43 AM, Flavien Charlon flavien.char...@coinprism.com wrote: My main concern with OP_RETURN is that it seems to encourage people to use the blockchain as a convenient transport channel The number one user of the blockchain as a storage and transport mechanism is Counterparty, and limiting OP_RETURN to 40 bytes didn't prevent them from doing so. In fact they use multi-sig outputs which is worse than OP_RETURN since it's not always prunable, and yet let them store much more than 40 bytes. For Open Assets https://github.com/OpenAssets/open-assets-protocol, we need to store a URL in the OP_RETURN output (with optionally a hash) plus some bytes of overhead. 40 bytes comes really short for that. The benefit of having a URL in there is that any storage mechanism can be used (Web, FTP, BitTorrent, MaidSafe...), whereas with only a hash, you have to hardcode the storing mechanism in the protocol (and even then, a hash is not enough to address a HTTP or FTP resource). Storing only a hash is fine for the most basic timestamping application, but it's hardly enough to build something interesting. I've counted the number of OP_RETURN outputs in the blockchain for the month of October 2014. There were 1,674 OP_RETURNs for a span of 4,659 blocks. Assuming they were all 40 bytes (the average is probably less than half of that), that means an increase of 14.37 bytes per block. Considering a 1 MB block, that's about 0.0013% of the block used up by OP_RETURN data in average. Increasing to 80 bytes will have a negligible impact on bandwidth and storage requirements, while being extremely useful for many use cases where a hash only is not enough. While I am not opposing the proposal, I am not sure about your statistics because while Counterparty is not currently using OP_RETURN encoding, you should factor in the number of CP transactions that would have been OP_RETURNs if they had been permitted (100,000 since inception according their blog[1] with monthly charts at their block explorer[2]). Refs: [1] http://counterparty.io/news/celebrating-10-transaction-on-the-counterparty-network/ [2] http://blockscan.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoind as a library
On Fri, Nov 28, 2014 at 5:22 PM, Oliver Egginger bitc...@olivere.de wrote: Sorry for the off-topic but while reading this I like to ask you for picocoin, see: https://github.com/jgarzik/picocoin For a research project I'm looking for a C library to operate some block chain analysis (parsing raw blocks and transactions). This might be useful for you https://github.com/MatthewLM/cbitcoin -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged
This is a pretty good example about refactoring discipline as well as premature/over optimisation. We all want to see more modular code, but the first steps should just be to relocate blocks of code so everything is more logically organised in smaller files (especially for consensus critical code). Refactoring should come in a second wave preferably after a stable release. Refactoring should be in the pure sense, optimising code with absolutely no change in behaviour. When it comes to actual API changes, I think we need to be a lot more careful and should be considered feature requests and get a lot more scrutiny as we are essentially breaking backwards compatibility. #4890 was pretty much merged with no discussion or thought yet other really simple and uncontroversial PRs remain unmerged for months. A key question in the case of EvalScript() would have been, why are we passing txTo and nIn here, and are there any future use cases that might require them? Why should this be removed from the API and the entire method signature changed?. BC breaks always need strong justification. So I've expressed my concern a few times about the speed and frequency of refactoring and also the way it's being done. I am not alone, as others not directly connected with the Bitcoin Core project have also expressed concerns about the number of refactorings for the sake of refactoring, especially of consensus critical code. Careful as we may be, we know from history that small edge case bugs can creep in very easily and cause a lot of unforeseen problems. BtcDrak On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd p...@petertodd.org wrote: BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few days ago and found a fairly large design change that makes merging it currently impossible. Pull-req #4890², specifically commit c7829ea7, changed the EvalScript() function to take an abstract SignatureChecker object, removing the txTo and nIn arguments that used to contain the transaction the script was in and the txin # respectively. CHECKLOCKTIMEVERIFY needs txTo to obtain the nLockTime field of the transaction, and it needs nIn to obtain the nSequence of the txin. We need to fix this if CHECKLOCKTIMEVERIFY is to be merged. Secondly, that this change was made, and the manner in which is was made, is I think indicative of a development process that has been taking significant risks with regard to refactoring the consensus critical codebase. I know I personally have had a hard time keeping up with the very large volume of code being moved and changed for the v0.10 release, and I know BtcDrak - who is keeping Viacoin up to date with v0.10 - has also had a hard time giving the changes reasonable review. The #4890 pull-req in question had no ACKs at all, and only two untested utACKS, which I find worrying for something that made significant consensus critical code changes. While it would be nice to have a library encapsulating the consensus code, this shouldn't come at the cost of safety, especially when the actual users of that library or their needs is still uncertain. This is after all a multi-billion project where a simple fork will cost miners alone tens of thousands of dollars an hour; easily much more if it results in users being defrauded. That's also not taking into account the significant negative PR impact and loss of trust. I personally would recommend *not* upgrading to v0.10 due to these issues. A much safer approach would be to keep the code changes required for a consensus library to only simple movements of code for this release, accept that the interface to that library won't be ideal, and wait until we have feedback from multiple opensource projects with publicly evaluatable code on where to go next with the API. 1) https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki 2) https://github.com/bitcoin/bitcoin/pull/4890 -- 'peter'[:-1]@petertodd.org 1b18a596ecadd07c0e49620fb71b16f9e41131df9fc52fa6 -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get
Re: [Bitcoin-development] ACK NACK utACK Concept ACK
Would someone also clarify the use of nit for nitpicking and how it plays in the role of consensus? It seems like it's used for minor complaints/preferences. Drak On Wed, Dec 10, 2014 at 3:52 PM, Jeff Garzik jgar...@bitpay.com wrote: On Wed, Dec 10, 2014 at 1:47 AM, Wladimir laa...@gmail.com wrote: Concept ACK - agree with the idea and overall direction, but haven't reviewed the code changes nor tested it Concept ACK - like the idea; the code may need rewriting (or haven't reviewed). -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Cartographer
Mike, In all seriousness, are you on the payroll of the NSA or similar to repeatedly attempt to introduce privacy leaks[1] and weaknesses[2] into the ecosystem not to mention logical fallacies like ad hominem attacks; disruption[3] and FUD[4]? Why do you answer objections by hand waving and misdirection as opposed to sound technical reasoning? Remember how hand waving ended for you the last time with your p2p getutxo pull-request[5] and the public flogging the ensued because you refused to accept your implementation was not only flawed but critically vulnerable to attack[6]. Given your intelligence, education and experience, it would seem logical that your behaviour is not random or irrational, but in fact calculated and planned. references: [1] http://www.reddit.com/r/Bitcoin/comments/2byqz0/mike_hearn_proposes_to_build_vulnerable/ [2] https://www.reddit.com/r/Bitcoin/comments/1qmbtu/mike_hearn_chair_of_the_bitcoin_foundations_law/ [3] http://www.reddit.com/r/Bitcoin/comments/28zts3/mike_hearn_interview_quotes_progress_on_the/ [4] https://www.youtube.com/watch?v=iMIzMVABFxQ [5] https://github.com/bitcoin/bitcoin/pull/4351 [6] http://www.reddit.com/r/Bitcoin/comments/2eq8gi/getutxos_a_convenient_way_to_crash_bitcoind/ -- 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] CLTV opcode allocation; long-term plans?
On Mon, May 4, 2015 at 6:07 AM, Peter Todd p...@petertodd.org wrote: Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool only CLTV pull-req²: I like merging this, but doing both CLTV things in one swoop would be really nice. Certainly if we're gonna use one of the precious few OP_NOPs we have we might as well make it more flexible. [snip] That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: relative nLockTime 2 OP_CLTV On the bad side it'd be two or three days of work to rewrite all the existing tests and example code and update the BIP, and (slightly) gets us away from the well-tested existing implementation. It also may complicate the codebase compared to sticking with just doing a Script v2.0, with the additional execution environment data required for v2.0 scripts cleanly separated out. But all in all, the above isn't too big of a deal. Adding a parameter to OP_CLTV makes it much more flexible and is the most economic use of precious NOPs. The extra time required is ok and it would be good to make this change to the PR in time for the feature freeze. Drak -- 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] Block Size Increase
On Thu, May 7, 2015 at 6:43 PM, Mike Hearn m...@plan99.net wrote: And I'll ask again. Do you have a *specific, credible alternative*? Because so far I'm not seeing one. I think you are rubbing against your own presupposition that people must find and alternative right now. Quite a lot here do not believe there is any urgency, nor that there is an immanent problem that has to be solved before the sky falls in. -- 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] Block Size Increase
On Thu, May 7, 2015 at 7:40 PM, Gavin Costin slashdevn...@hotmail.com wrote: Can anyone opposed to this proposal articulate in plain english the worst case scenario(s) if it goes ahead? Some people in the conversation appear to be uncomfortable, perturbed, defensive etc about the proposal …. But I am not seeing specifics on why it is not a feasible plan. See this response: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07462.html -- 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] Block Size Increase
On Thu, May 7, 2015 at 5:11 PM, Mike Hearn m...@plan99.net wrote: Right now there is this nice warm fuzzy notion that decisions in Bitcoin Core are made by consensus. Controversial changes are avoided. I am trying to show you that this is just marketing. Consensus is arrived when the people who are most active at the time (active in contributing to discussions, code review, giving opinions etc.) agreed to ACK. There are a regular staple of active contributors. Bitcoin development is clearly a meritocracy. The more people participate and contribute the more weight their opinions hold. Nobody can define what these terms even mean. It would be more accurate to say decisions are vetoed by whoever shows up and complains enough, regardless of technical merit. After all, my own getutxo change was merged after a lot of technical debate (and trolling) . then unmerged a day later because it's a shitstorm. I am not sure that is fair, your PR was reverted because someone found a huge exploit in your PR enough to invalidate all your arguments used to get it merged in the first place. So if Gavin showed up and complained a lot about side chains or whatever, what you're saying is, oh that's different. We'd ignore him. But when someone else complains about a change they don't like, that's OK. Heck, I could easily come up with a dozen reasons to object to almost any change, if I felt like it. Would I then be considered not a part of the consensus because that'd be convenient? I don't think it's as simple as that. Objections for the sake of objections, or unsound technical objections are going to be seen for what they are. This is a project with of some of the brightest people in the world in this field. Sure people can be disruptive but their reputation stand the test of time. The consensus system might not be perfect, but it almost feels like you want to declare a state of emergency and suspend all the normal review process for this proposed hard fork. -- 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] Block Size Increase
On Thu, May 7, 2015 at 3:05 PM, Mike Hearn m...@plan99.net wrote: Maybe you dislike that idea. It's so centralised. So let's say Gavin commits his patch, because his authority is equal to all other committers. Someone else rolls it back. Gavin sets up a cron job to keep committing the patch. Game over. You cannot have committers fighting over what goes in and what doesn't. That's madness. There must be a single decision maker for any given codebase. You are conflating consensus with commit access. People with commit access are maintainers who are *able to merge* pull requests. However, the rules for bitcoin development are that only patches with consensus get merged. If any of the maintainers just pushed a change without going through the whole code review and consensus process there would be uproar, plain and simple. Please don't conflate commit access with permission to merge because it's just not the case. No-one can sidestep the requirement to get consensus, not even the 5 maintainers. -- 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] CLTV opcode allocation; long-term plans?
Gavin and @NicolasDorier have a point: If there isn't actually scarcity of NOPs because OP_NOP10 could become type OP_EX (if we run out), it makes sense to chose the original unparameterised CLTV version #6124 which also has been better tested. It's cleaner, more readable and results in a slightly smaller script which has also got to be a plus. On Tue, May 12, 2015 at 8:16 PM, Jorge Timón jti...@jtimon.cc wrote: This saves us ocodes for later but it's uglier and produces slightly bigger scripts. If we're convinced it's worth it, seems like the right way to do it, and certainly cltv and rclv/op_maturity are related. But let's not forget that we can always use this same trick with the last opcode to get 2^64 brand new opcodes. So I'm not convinced at all on whether we want #5496 or #6124. But it would be nice to decide and stop blocking this. On Sat, May 9, 2015 at 11:12 AM, Peter Todd p...@petertodd.org wrote: On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote: That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could then be a future soft-fork implemented as follows: relative nLockTime 2 OP_CLTV On the bad side it'd be two or three days of work to rewrite all the existing tests and example code and update the BIP, and (slightly) gets us away from the well-tested existing implementation. It also may complicate the codebase compared to sticking with just doing a Script v2.0, with the additional execution environment data required for v2.0 scripts cleanly separated out. But all in all, the above isn't too big of a deal. Adding a parameter to OP_CLTV makes it much more flexible and is the most economic use of precious NOPs. The extra time required is ok and it would be good to make this change to the PR in time for the feature freeze. Done! https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263 -- 'peter'[:-1]@petertodd.org 12c438a597ad15df697888be579f4f818a30517cd60fbdc8 -- 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] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit
On Mon, Jun 8, 2015 at 11:01 PM, Raystonn . rayst...@hotmail.com wrote: No, with no blocksize limit, a spammer would would flood the network with transactions until they ran out of money. I think you are forgetting even if you remove the blocksize limit, there is still a hard message size limit imposed by the p2p protocol. Block would de-facto be limited to this size. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
I did wonder what the post actually meant, I recommend appending /s after sarcasm so it's clear. Lots gets lost in text. But I agree with you btw his response was not particularly tactful. On Mon, Jun 1, 2015 at 7:19 PM, Warren Togami Jr. wtog...@gmail.com wrote: By reversing Mike's language to the reality of the situation I had hoped people would realize how abjectly ignorant and insensitive his statement was. I am sorry to those in the community if they misunderstood my post. I thought it was obvious that it was sarcasm where I do not seriously believe particular participants should be excluded. On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle thyshiz...@outlook.com wrote: Doesn't mean you should build something that says fuck you to the companies that have invested in farms of ASICS. To say Oh yea if they can't mine it how we want stuff 'em is naive. I get decentralisation, but don't dis incentivise mining. If miners are telling you that you're going to hurt them, esp. Miners that combined hold 50% hashing power, why would you say too bad so sad? Why not just start stripping bitcoin out of adopters wallets? Same thing. -- From: Warren Togami Jr. wtog...@gmail.com Sent: 1/06/2015 10:30 PM Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements Whilst it would be nice if miners in *outside* China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in *outside* China can't get the trivial amounts of bandwidth required through their firewall *TO THE MAJORITY OF THE HASHRATE* and end up being outcompeted then OK, too bad, we'll have to carry on without them. On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn m...@plan99.net wrote: Whilst it would be nice if miners in China can carry on forever regardless of their internet situation, nobody has any inherent right to mine if they can't do the job - if miners in China can't get the trivial amounts of bandwidth required through their firewall and end up being outcompeted then OK, too bad, we'll have to carry on without them. But I'm not sure why it should be a big deal. They can always run a node on a server in Taiwan and connect the hardware to it via a VPN or so. -- ___ 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
