Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On 18 June 2015 at 12:00, Mike Hearn wrote: > Dude, calm down. I don't have commit access to Bitcoin Core and Gavin > already said long ago he wouldn't just commit something, even though he has > the ability to do so. > > So why did I say it? Because it's consistent with what I've always said: >

Re: [Bitcoin-development] Long-term mining incentives

On 11 May 2015 at 18:28, Thomas Voegtlin wrote: > The discussion on block size increase has brought some attention to the > other elephant in the room: Long-term mining incentives. > > Bitcoin derives its current market value from the assumption that a > stable, steady-state regime will be reache

Re: [Bitcoin-development] [ANN] METAmarket - Trustless Federated Marketplaces

On 2 May 2015 at 00:57, Marc D. Wood wrote: > METAmarket: Trustless Federated Marketplaces > >>> http://metamarket.biz <<< > > * * * > Introduction > > METAmarket is an open source protocol and proof-of-concept reference > client specifying a trustless federated marketplace which uses Bitcoin as

Re: [Bitcoin-development] Running a full node

On 8 November 2014 16:28, Daniel F wrote: > > But I'd like to know what storage, RAM and bandwidth resources are > > needed. I guess that the problem is not the CPU. > > Hi Francis, > > Here are some rough guidelines for you, based on the statistics from my > node: > > disk usage: about 30GB cur

Re: [Bitcoin-development] side-chains & 2-way pegging (Re: is there a way to do bitcoin-staging?)

On 22 October 2014 23:54, Adam Back wrote: > For those following this thread, we have now written a paper > describing the side-chains, 2-way pegs and compact SPV proofs. > (With additional authors Andrew Poelstra & Andrew Miller). > > http://blockstream.com/sidechains.pdf > A very well written

Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

On 27 October 2014 08:49, Wladimir wrote: > On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho > wrote: > > > Firstly, apologies in coming in late to the conversation. As I am also > > working on a REST API for electronic coins. Some questions: > > > > 1. Is th

Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

On 26 October 2014 08:57, Wladimir wrote: > Now that headers-first is merged it would be good to do a 0.10 release > soon. Not *too* soon as a major code change like that takes some time > to pan out, but I'd like to propose the following: > > - November 18: split off 0.10 branch, translation mes

Re: [Bitcoin-development] death by halving

On 26 October 2014 00:10, Ross Nicoll wrote: > I'd suggest looking at how Dogecoin's mining schedule has worked out, for > how halvings tend to actually affect the market. Part of Dogecoin's design > was that it would halve very quickly (around every 75 days, in fact), so > it's essentially illu

Re: [Bitcoin-development] death by halving

On 25 October 2014 21:53, Alex Mizrahi wrote: > > We had a halving, and it was a non-event. >> Is there some reason to believe next time will be different? >> > > Yes. > > When the market is rapidly growing, margins can be relatively high because > of limited amounts of capital being invested, or

Re: [Bitcoin-development] Fwd: [Bug 24444] Named Curve Registry (adding secp256k1)

> > Matt > > On 10/13/14 10:01, Melvin Carvalho wrote: > > FYI: > > > > This is an issue I filed related to adding secp256k1 into Web Crypto API > > which will be implemented natively in (some) web browsers. > > > > If there is any feedback from cr

[Bitcoin-development] Fwd: [Bug 24444] Named Curve Registry (adding secp256k1)

FYI: This is an issue I filed related to adding secp256k1 into Web Crypto API which will be implemented natively in (some) web browsers. If there is any feedback from crypto implementers, please feel free to add comments to this thread: https://www.w3.org/Bugs/Public/show_bug.cgi?id=2 --

Re: [Bitcoin-development] [ann] Bitcoin Core 0.9.3 has been released

On 27 September 2014 15:56, Wladimir wrote: > Bitcoin Core version 0.9.3 is now available from: > > https://bitcoin.org/bin/0.9.3/ > > This is a new minor version release, bringing only bug fixes and updated > translations. Upgrading to this release is recommended. > > Please report bugs using

Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

On 15 September 2014 09:23, Thomas Zander wrote: > On Sunday 14. September 2014 08.28.27 Peter Todd wrote: > > Do we have any evidence Satoshi ever even had access to that key? Did he > > ever use PGP at all for anything? > > Any and all PGP related howtos will tell you that you should not trust

[Bitcoin-development] Mining Hashrate Caps

I noticed this article today. GHash Commits to 40% Hashrate Cap at Bitcoin Mining Summit http://www.coindesk.com/ghash-commits-40-hashrate-cap-bitcoin-mining-summit/ Here's a quote from Satoshi when the mining arms race began: "We should have a gentleman’s agreement to postpone the GPU arms rac

Re: [Bitcoin-development] moving the default display to mbtc

On 14 November 2013 12:45, Melvin Carvalho wrote: > Rationale > === > > Given the recent rise in value there seems to be anecdotal evidence that 1 > bitcoin being so high is putting off a lot of normal buyers, because they > feel that putting down $400+ and only getting &

Re: [Bitcoin-development] Proposal for extra nonce in block header

On 27 April 2014 09:07, Timo Hanke wrote: > I'd like to put the following draft of a BIP up for discussion. > > Timo > > # Abstract > There are incentives for miners to find cheap, non-standard ways to > generate new work, which are not necessarily in the best interest of the > protocol. > In ord

Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)

On 16 April 2014 10:14, Wladimir wrote: > Hello, > > Today I noticed that even my bank is warning people to not do internet > banking with Windows XP. > > If it is no longer secure enough for online banking it's CERTAINLY not > secure enough to run a wallet (for a node only it would be ok-ish as

Re: [Bitcoin-development] Bitcoin for W3C Payments Workshop, March 24-25

On 20 March 2014 02:41, Odinn Cyberguerrilla < odinn.cyberguerri...@riseup.net> wrote: > I wish to state that I fundamentally disagree with this proposal of use > cases for W3C payments workshop. Please read my following explanation and > then do what you will: > > At one time I was invited to jo

Re: [Bitcoin-development] moving the default display to mbtc

On 13 March 2014 16:50, Mike Hearn wrote: > On Thu, Mar 13, 2014 at 3:32 PM, Jeff Garzik wrote: > >> Such hand-wavy, data-free logic is precisely why community >> coordination is preferred to random apps making random decisions in >> this manner. >> > > That ship sailed months ago. If you wanted

Re: [Bitcoin-development] Testnet block explorer

On 27 December 2013 19:05, Mike Hearn wrote: > For a long time the only block explorer for testnet has been the original > blockexplorer.com, which is unfortunately often broken / behind / slow > and not really maintained any more. > > There is now a new one, here: > > https://www.biteasy.com/tes

Re: [Bitcoin-development] BIP: register with IANA for bitcoin/cryptocoin port numbers

On 3 January 2014 06:22, Troy Benjegerdes wrote: > I believe this is self-explainatory: > > 1) Bitcoin usually runs on port 8333. Why? > > 2) Bitcoin does not show in up > http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml.. > why? > > 3) What needs to ha

Re: [Bitcoin-development] Happy new year!

On 1 January 2014 19:33, Mike Hearn wrote: > Bitcoin had an incredible year in 2013, and I very much enjoyed working > with and meeting you all. > > I'm very much looking forward to some of the upgrades coming in 2014. > Though a lot happened in the general community, last year was kind of quiet

Re: [Bitcoin-development] Testnet block explorer

On 27 December 2013 19:08, Mike Belshe wrote: > Great! > > There is another one at http://testnet.btclook.com/ which provides a > different view as well. > And another at: http://test.webbtc.com/ Testnet does not currently full

[Bitcoin-development] Web Crypto -- Named Curve Dictionary (adding secp256k1)

Harry and David suggested I send a message to this group. I was wondering if the crypto group may consider adding support for *secp256k1* in the browser Named Curve dictionary. http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary enum NamedCurve { // NIST recommended curve P-256, also

Re: [Bitcoin-development] Message Signing based authentication

On 6 November 2013 07:41, slush wrote: > > But where are the private keys stored? Crypto in the browser with help, > but although they will expose ECC via the NSS, I dont think bitcoin's > particular curve will be supported, because it's not NIST approved. If the > use case was presented though,

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

On 14 October 2013 20:08, Adam Back wrote: > Coming back to the staging idea, maybe this is a realistic model that could > work. The objective being to provide a way for bitcoin to move to a live > beta and stable being worked on in parallel like fedora vs RHEL or odd/even > linux kernel version

Re: [Bitcoin-development] moving the default display to mbtc

On 15 November 2013 01:37, Daniel F wrote: > > This is a decentralized currency, and we should avoid centralizing > > decisions. This is something that impacts the community at large, and > > deserves input and discussion at every level. > > > > I would suggest posting on all possible forums "pr

[Bitcoin-development] moving the default display to mbtc

Rationale === Given the recent rise in value there seems to be anecdotal evidence that 1 bitcoin being so high is putting off a lot of normal buyers, because they feel that putting down $400+ and only getting "1 coin", or having to buy in multiples of 1 whole coin, is too much.. only after it

Re: [Bitcoin-development] we can all relax now

On 6 November 2013 06:33, kjj wrote: > One of the things that really gets me going is when someone devises a > model, tests it against itself, and then pretends that they've learned > something about the real world. > > Naturally, the Selfish Mining paper is exactly this sort of nonsense. > Their

Re: [Bitcoin-development] Message Signing based authentication

On 2 November 2013 22:14, Johnathan Corgan wrote: > On 11/01/2013 10:01 PM, bitcoingr...@gmx.com wrote: > > > Server provides a token for the client to sign. > > Anyone else concerned about signing an arbitrary string? Could be a > hash of $EVIL_DOCUMENT, no? I'd want to XOR the string with my

Re: [Bitcoin-development] Message Signing based authentication

On 2 November 2013 22:57, slush wrote: > Glad to see that there are more and more people wanting to replace > passwords with digital signatures. > > Although such method has been already used on other websites like Eligius > or bitcoin-otc, I dont think theres any standard way to doing so yet. >

Re: [Bitcoin-development] Message Signing based authentication

On 2 November 2013 17:26, Mike Hearn wrote: > Guys, identity systems for the web are off-topic for this list. Other than > the anonymous passports/SINs/fidelity bond ideas, Bitcoin doesn't have any > relevance to it. > > On Sat, Nov 2, 2013 at 2:19 PM, Hannu Kotipalo wrote: > >> Maybe this is a b

Re: [Bitcoin-development] Message Signing based authentication

On 2 November 2013 14:02, Mike Hearn wrote: > On Sat, Nov 2, 2013 at 6:01 AM, wrote: > >> In brief, the authentication work as follows: >> >> >> >> Server provides a token for the client to sign. >> >> client passes the signed message and the bitcoin address back to the >> server. >> >> server v

[Bitcoin-development] Core Development Update #5

https://bitcoinfoundation.org/blog/?p=290 Very excited about this, particularly the 80 bytes embeddable message. I do believe satoshi mentioned he wanted to add short messages, at some point. Great work Gavin & all! -- O

Re: [Bitcoin-development] A critique of bitcoin open source community

On 21 October 2013 09:03, Martin Sustrik wrote: > On 21/10/13 08:52, Jean-Paul Kogelman wrote: > > How about putting them into sub directories that map onto the status of > the BIP? > > > > Reading BIP 1, that would make: > > > > Accepted > > Active > > Draft > > Deferred > > Final > > Rejected >

Re: [Bitcoin-development] A critique of bitcoin open source community

On 19 October 2013 18:38, Mitar wrote: > Hi! > > Interesting read: > > > http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html > Im sympathetic to some of the points, but it seems slightly harsh. I do agree that we're lucky to have the excellent leadership of Gavin,

Re: [Bitcoin-development] Bitcoin meets the Semantic Web....

On 1 April 2013 09:59, Melvin Carvalho wrote: > I'm working on porting crypto currencies to the semantic web. > > The advantages of this is that pages can then become machine readable on > the web allowing new types of innovation and spreading bitcoin information > to a wid

Re: [Bitcoin-development] smart contracts -- possible use case? yes or no?

On 29 September 2013 04:28, Neil Fincham wrote: > I subscribe to this list so I can keep up-to date with bitcoin > development, can we keep philosophy and tax evasion out of it? > Hi Neil, perhaps I didnt present the use case clearly. It was not about evasion, it was about voluntary donations g

Re: [Bitcoin-development] smart contracts -- possible use case? yes or no?

On 29 September 2013 10:32, Gavin Andresen wrote: > On Sun, Sep 29, 2013 at 12:28 PM, Neil Fincham wrote: > >> I subscribe to this list so I can keep up-to date with bitcoin >> development, can we keep philosophy and tax evasion out of it? >> > > Yes, that's off-topic for this mailing list. Lets

[Bitcoin-development] smart contracts -- possible use case? yes or no?

We all love bitcoin's ability to transfer value in real time across borders. But the regulatory environment in many geographical regions in uncertain. Do we need to pay capital gains? Do we need to pay a sales taxs etc. etc. At this point bitcoin is small enough for this to not be a huge issue,

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

On 25 September 2013 13:15, Mike Hearn wrote: > It won't fit. But I don't see the logic. A URI contains instructions for > making a payment. If that instruction is "pay to this address" or "download > this file and do what you find there", it's no different unless there's > potential for a MITM a

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

On 16 August 2013 03:00, Gavin Andresen wrote: > Mike asked what non-0.9 code I'm working on; the three things on the top > of my list are: > > 1) Smarter fee handling on the client side, instead of hard-coded fees. I > was busy today generating scatter-plots and histograms of transaction fees >

Re: [Bitcoin-development] Version 0.9 goals

On 15 August 2013 02:29, Gavin Andresen wrote: > It feels to me like we're close to a 0.9 "feature freeze" / start of > release cycle; I'd like to talk a little bit about what we'd like to see in > the final 0.9 release. > > My list: > > Bug: I'd really like to see the leveldb corruption issue (

Re: [Bitcoin-development] Idea for new payment protocol PKI

On 9 August 2013 13:59, Wendell wrote: > We have been discussing something like this over here too, as well as > exploring more esoteric blockchain+signature-based "SSO" implementations as > discussed by John Light and others. > I've been using SSO for years using an X.509 private key in my brow

Re: [Bitcoin-development] Idea for new payment protocol PKI

On 9 August 2013 14:08, Mike Hearn wrote: > Bitcoin sought to reduce dependence on trusted third parties, where as, >> persona is increasing the reach of trusted third parties. The keys and >> passwords are stored on mozilla's servers, sometimes on your email >> providers. Persona, is however,

Re: [Bitcoin-development] Idea for new payment protocol PKI

On 9 August 2013 13:43, Mike Hearn wrote: > This is just me making notes for myself, I'm not seriously suggesting this > be implemented any time soon. > > Mozilla Persona is an infrastructure for web based single sign on. It > works by having email providers sign temporary certificates for their

[Bitcoin-development] Preparing for the Cryptopocalypse

A great presentation on advances in crypto http://www.slideshare.net/astamos/bh-slides -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up.

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

On 31 July 2013 13:33, Gavin Andresen wrote: > On Wed, Jul 31, 2013 at 6:45 PM, Roy Badami wrote: > > > > Is it envisaged to be possible/sensible to have a URI that is *only* a > > payment request? i.e. something like the following (although I'm not > > sure this is a valid URI): > > > > bitcoi

Re: [Bitcoin-development] [RFC] Standard for private keys with birth timestamp

On 22 July 2013 16:44, Pieter Wuille wrote: > Hello, > > I should have brought up this suggestion before, as there seems to be > relevant other work. > > I'd like to propose encoding keys data (whatever type) with a birth > timestamp as: > * @ > > The reason for not incorporating this inside the

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

On 10 June 2013 06:09, John Dillon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > It has been suggested that we leave the decision of what the blocksize to > be > entirely up to miners. However this leaves a parameter that affects every > Bitcoin participant in the control of a sm

Re: [Bitcoin-development] Bitcoin addresses -- opaque or not

On 11 June 2013 17:29, Luke-Jr wrote: > On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote: > > For the sake of argument let's say that opaque means that you can tell > > nothing about the address by examining the characters. > > This is true or false based on

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

On 18 June 2013 05:48, Alan Reiner wrote: > *Goal*: An alternative address format made possible by BIP 32, which > allows one to specify a "Wallet ID" and "One-time payment" code, instead of > the standard one-use Base58-Hash160 addresses. This allows parties with a > persistent relationship

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

On 19 May 2013 15:23, Adam Back wrote: > Is there a way to experiment with new features - eg committed coins - that > doesnt involve an altcoin in the conventional sense, and also doesnt impose > a big testing burden on bitcoin main which is a security and testing risk? > > eg lets say some form

Re: [Bitcoin-development] Bitcoin addresses -- opaque or not

On 11 June 2013 17:29, Luke-Jr wrote: > On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote: > > For the sake of argument let's say that opaque means that you can tell > > nothing about the address by examining the characters. > > This is true or false based on

[Bitcoin-development] Fwd: The "pay it forward approach" to crypto currencies

FYI: some musings on how crypto currencies might be combined with social good ... -- Forwarded message -- From: Melvin Carvalho Date: 12 June 2013 19:39 Subject: The "pay it forward approach" to crypto currencies To: building-a-distributed-decentralized-inter...@google

[Bitcoin-development] Bitcoin addresses -- opaque or not

There was some confusion on IRC as to whether bitcoin addresses are opaque or not. https://en.bitcoin.it/wiki/Address For the sake of argument let's say that opaque means that you can tell nothing about the address by examining the characters. My understanding was that they are NOT opaque, and t

Re: [Bitcoin-development] Decentralizing mining

On 10 June 2013 23:09, Peter Todd wrote: > So here's the parts that need to be done for step #1: > > > # Protocol Work > > Basic idea is the miner makes two connections, their pool, and a local > bitcoind. > > They always (usually?) work on the subset of transactions common to both > the pool's g

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

On 10 June 2013 10:35, Pieter Wuille wrote: > On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho > wrote: > > However, Bitcoin's fundamental philosophy was one CPU one vote. > > This is perhaps the largest misconception that keeps being repeated. > Bitcoin is not a dem

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

On 10 June 2013 10:26, John Dillon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Mon, Jun 10, 2013 at 8:14 AM, Melvin Carvalho > wrote: > > -1 > > > > Firstly I appreciate the ingenious thought that went into this post. > > > >

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

On 10 June 2013 06:09, John Dillon wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > It has been suggested that we leave the decision of what the blocksize to > be > entirely up to miners. However this leaves a parameter that affects every > Bitcoin participant in the control of a sm

Re: [Bitcoin-development] Revocability with known trusted escrow services?

On 6 June 2013 02:19, Peter Vessenes wrote: > So, this > http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 > article got posted today, noting that FinCEN thinks irrevocable payments > are money laundering tools. > > I will hold my thoughts about the net socia

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

On 6 June 2013 23:48, Luke-Jr wrote: > On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote: > > > This doesn't work like you might think: first of all, the fees today > are > > > greatly subsidized - the actual cost to store data in the blockchain is > > > much higher than most st

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

On 6 June 2013 21:59, Andreas M. Antonopoulos wrote: > Is there any consideration given to the fact that bitcoin can operate as a > platform for many other services, if it is able to be neutral to payload, > as long as the fee is paid for the transaction size? > > Unless I have misunderstood this

[Bitcoin-development] address collision and undependability

There was a discussion on #bitcon-dev yesterday I stated that it would be impractical to generate two bitcoin addresses, such that they differed in exactly one character (modulo different checksums). The corollary to this is that if you find an address with a verifiable signature. Changing one c

Re: [Bitcoin-development] Revocability with known trusted escrow services?

On 6 June 2013 02:19, Peter Vessenes wrote: > So, this > http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1 > article got posted today, noting that FinCEN thinks irrevocable payments > are money laundering tools. > It's great that this article quotes the firs

[Bitcoin-development] Fwd: Creating a Currency for the (Read / Write) Web

FYI: I think this may be a possible blue print for a web version of bitcoin+ripple combined. -- Forwarded message -- From: Melvin Carvalho Date: 5 June 2013 18:50 Subject: Creating a Currency for the (Read / Write) Web To: public-rww , Nathan Rixham , Web Payments I've

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

On 1 June 2013 21:30, Peter Todd wrote: > Currently the most compact way (proof-size) to sacrifice Bitcoins that > does not involve making them unspendable is to create a anyone-can-spend > output as the last txout in the coinbase of a block: > > scriptPubKey: OP_TRUE > > The proof is then the S

Re: [Bitcoin-development] WebCryto standard to support secp256r1 but not secp256k1

On 7 May 2013 12:18, Melvin Carvalho wrote: > Looking at the proposed native crypto browser support (should arrive in > the next year) > > http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary > > We see: > > enum NamedCurve { > // NIST recommended curve P-2

Re: [Bitcoin-development] (no subject)

On 25 May 2013 10:53, Luke-Jr wrote: > On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote: > > It might be an idea to have 'rule change' fixes and 'bug fix' releases go > > out separately > > Bitcoin is a consensus system. You can't ru

Re: [Bitcoin-development] (no subject)

On 25 May 2013 07:46, Zooko Wilcox-OHearn wrote: > jgarzik wrote: > > 1) Rule changes. We don't want these. > > In general? What constitutes a rule change? > > For example, if I understand correctly (from what Gavin said at > Bitcoin 2013), there is a move afoot to lift the block size limit. >

Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

On 22 May 2013 16:07, Jeff Garzik wrote: > On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho > wrote: > > Some out of band algo/hash could work so long as there was a one to one > > relationship between the described object and the UUID. In this case the > > gensi

Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

On 21 May 2013 01:59, Mark Friedenbach wrote: > At the developer round-table it was asked if the payment protocol would > alt-chains, and Gavin noted that it has a UTF-8 encoded string > identifying the network ("main" or "test"). As someone with two > proposals in the works which also require ch

Re: [Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy

On 15 May 2013 13:38, Peter Todd wrote: > Now that I have the replace-by-fee reward, I might as well spread the > wealth a bit. > > > So for all this discussion about replace-by-fee and the supposed > security of zero-conf transactions, no-one seems to think much about how > in practice very few

Re: [Bitcoin-development] Bitcoin2013 Speakers: Include your PGP fingerprint in your slides

On 14 May 2013 20:41, Peter Todd wrote: > report: https://bitcointalk.org/index.php?topic=205349.0 > > Every talk will be widely witnessed and videotaped so we can get some > reasonably good security by simply putting out PGP fingerprints in our > slides. Yeah, some fancy attacker could change th

[Bitcoin-development] WebCryto standard to support secp256r1 but not secp256k1

Looking at the proposed native crypto browser support (should arrive in the next year) http://www.w3.org/TR/WebCryptoAPI/#EcKeyGenParams-dictionary We see: enum NamedCurve { // NIST recommended curve P-256, also known as secp256r1. "P-256", // NIST recommended curve P-384, also known as se

Re: [Bitcoin-development] Sending Bitcoins using RSA keys

ding snarky or > dismissive; it's not intended that way. I'm wondering if I'm missing > the > big picture. > Not snarky at all! Appreciate the feedback... > > On Wed, Apr 24, 2013 at 04:18:38PM +0200, Melvin Carvalho wrote: > > So there&#x

Re: [Bitcoin-development] BIP21 bitcoin URIs and HTML5

On 24 April 2013 09:42, Mike Hearn wrote: > HTML5 allows web apps to register themselves for handling URI schemes, > such as the bitcoin: URI that is already in use and being extended as part > of the payment protocol. > > The bad news is that for security reasons there is a whitelist of > accept

[Bitcoin-development] Sending Bitcoins using RSA keys

So there's a slight world divide in digital payments with bitcoin using ECDSA and GPG, payswarm / webid etc using largely RSA Here's how to bring the two worlds together and enable bitcoins be sent over webid or payswarm Problem: Alice and Bob have RSA key pairs, but no public bitcoin addresses.

[Bitcoin-development] Web Payments with PaySwarm: Identity (part 1 of 3)

FYI: this is worth a read for anyone interested in the payment ecosystem on the WWW ... it's about 5 years of work, and there's a even hope to integrate bitccoin too ... https://hacks.mozilla.org/2013/04/web-payments-with-payswarm-identity-part-1-of-3/ I've cc'd Manu in case anyone here has any q

Re: [Bitcoin-development] A mining pool at 46%

but I think p2pool still has a lot of problems dealing with > FPGA/ASIC hardware and it hasn't been growing for a long time. > I guess the market will decide which algorithm is used, but as a community we can perhaps review the different mining protocols and order them in terms of ri

[Bitcoin-development] A mining pool at 46%

There was some chat on IRC about a mining pool reaching 46% http://blockchain.info/pools What's the risk of a 51% attack. I suggested that the pool itself is decentralized so you could not launch one On IRC people were saying that the pool owner gets to choose what goes in the block Surely wit

Re: [Bitcoin-development] bitcoin pull requests

log/archives/2012/10/when_will_we_se.html We're talking about a million terrahashes = 2^60 right? With the block chain, you only have a 10 minute window, but with source code you have a longer time to prepare. Couldnt this be done with an ASIC in about a week? > > Will > >

Re: [Bitcoin-development] bitcoin pull requests

it might be more feasible to > cause problems in the chain by e.g. constantly splitting it. > OK, maybe im being *way* too paranoid here ... but what if someone had access to github, could they replace one file with one they had prepared at some point? > > > On 1 April 2013 03:26

Re: [Bitcoin-development] Bitcoin meets the Semantic Web....

On 1 April 2013 11:35, Harald Schilly wrote: > On Mon, Apr 1, 2013 at 9:59 AM, Melvin Carvalho > wrote: > > The first step that needs to be done is to create a "vocabulary" for > > bitcoin. > > Hi, have you checked out databases like OKFN and searched for exist

[Bitcoin-development] bitcoin pull requests

I was just looking at: https://bitcointalk.org/index.php?topic=4571.0 I'm just curious if there is a possible attack vector here based on the fact that git uses the relatively week SHA1 Could a seemingly innocuous pull request generate another file with a backdoor/nonce combination that slips un

[Bitcoin-development] Bitcoin meets the Semantic Web....

I'm working on porting crypto currencies to the semantic web. The advantages of this is that pages can then become machine readable on the web allowing new types of innovation and spreading bitcoin information to a wider audience. The first step that needs to be done is to create a "vocabulary" f

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

On 17 December 2012 10:19, Mike Hearn wrote: > Can we please drop the binary vs text issue? We have been around it > millions of times already. There are no compelling arguments to use > text here and several obvious problems with it. If you think you've > found a good argument to use JSON, pleas

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

On 17 December 2012 03:18, Jeff Garzik wrote: > On Sun, Dec 16, 2012 at 4:15 PM, Melvin Carvalho > wrote: > > On 3 December 2012 20:35, Mike Koss wrote: > >> It would also be really nice to migrate to textual representations of > data > >> structures as

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

On 3 December 2012 20:35, Mike Koss wrote: > The thing that bugged me most about the original spec was the sole > reliance on X.509 - glad to see you've made that optional. I think many > people will balk at deferring our identity trust to the existing CA's. I > think it's a fine bootstrap meth