Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Adam Back
Bitcoin p2p seeding requirements hav some ToR similarities, and we went through the same security considerations with Zero-Knowledge systems freedom network. Though bitcoins attacker profile and motivation is different - so the defense maybe even more demanding. At least you have no shortage of

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Adam Back
On Mon, May 06, 2013 at 03:08:57PM -0400, Peter Todd wrote: Hmm: maybe one could use a Brands private credential with offline double spend detection, with the reputation but not coin address of the node disclosed, and the nodes coin address embedded in the proof. Each node could be is own CA,

[Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)

2013-05-06 Thread Adam Back
On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote: On Mon, May 6, 2013 at 11:04 AM, Adam Back a...@cypherspace.org wrote: bitcoins primaryvulnerability IMO (so far) is network attacks to induce network splits, local lower difficulty to a point that a local and artificially

Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key

2013-05-07 Thread Adam Back
07, 2013 at 02:16:41PM +0200, Adam Back wrote: Hi Three minor security/other issues: 1. please a way to unlock the wallet without displaying wallet password in console screen (console unlock wallet, to import priv key); or I think the general solution here is providing a feature-reach

Re: [Bitcoin-development] An initial replace-by-fee implementation is now available

2013-05-09 Thread Adam Back
In this thread discussing this idea https://bitcointalk.org/index.php?topic=179612.0 it is suggested that the approach risks making 0-confirm double-spends easier. I dont see why this should be. Cant part of the validation of accepting a fee revision be that every aspct of the revision except

[Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-11 Thread Adam Back
I didnt quite understand the writeup and the references were ambiguous. But if you are talking about bitcoin/hashcash merged mining for email: it is something I think should possible. Of course for email the scale means bitcoin style flood-fill and direct tiny payments are completely out of the

Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-13 Thread Adam Back
On Mon, May 13, 2013 at 07:31:21AM +, John Dillon wrote: [with] merge-mining [you get] more value from just one unit of work. correct. But Peter's coinbase hashcash protocol carefully ensures [...] the amount of value the miner would have then given away in a anyone-can-spend output. I

Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-13 Thread Adam Back
, Adam Back a...@cypherspace.org wrote: On Mon, May 13, 2013 at 07:31:21AM +, John Dillon wrote: [with] merge-mining [you get] more value from just one unit of work. correct. But Peter's coinbase hashcash protocol carefully ensures [...] the amount of value the miner would have then given away

Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-14 Thread Adam Back
On Mon, May 13, 2013 at 06:00:27PM -0400, Jeff Garzik wrote: When a transaction's input value exceeds its output value, the remainder is the transaction fee. The miner's reward for processing transactions is the 25 BTC initial currency distribution + the sum of all per-transaction fees. A

[Bitcoin-development] ecash and revocability

2013-05-14 Thread Adam Back
So back in 1999, in an ecash thread on cypherpunks I claimed: http://marc.info/?l=cypherpunksm=95280154629900w=2 I wouldn't say ecash has to use blinding, but I would argue it would be a misuse of the word ecash, if something which was revocable were dubbed ecash. This was in the context of

[Bitcoin-development] bitcoin taint unilateral revocability (Re: ecash and revocability)

2013-05-14 Thread Adam Back
On Tue, May 14, 2013 at 01:51:51PM +0200, Adam Back wrote: Adam Back in Sep 1999, cypherpunks list: I wouldn't say ecash has to use blinding, but I would argue it would be a misuse of the word ecash, if something which was revocable were dubbed ecash. So I still think that is an important point

Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-14 Thread Adam Back
On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote: Well if it is a later transaction, not an integral part of the reward transaction (that is definitionally mined by being serialized into the coinbase), the user may elect to withhold the promised transaction give-to-miner, so thats

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

2013-05-14 Thread Adam Back
On Tue, May 14, 2013 at 09:39:46PM +0200, Harald Schilly wrote: If you have your own domain, you can store your key there as a TXT entry. $ dig +short harald._pka.schil.ly. TXT and even use it automatically: $ gpg … --auto-key-locate pka -r email@address.domain Nice. But we all kow about the

[Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Adam Back
process. That admits more interesting things like pool free direct mining, low variance hashcash coins, probably. Many things to think through. I suppose the commitment could be described as a blind symmetric commitment. Adam On Tue, May 14, 2013 at 04:09:02PM +0200, Adam Back wrote: [...] One

[Bitcoin-development] double-spend deletes (or converts to fees) (Re: reward for making probabalistic double-spending via conflicting transactions easy)

2013-05-15 Thread Adam Back
On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote: no-one seems to think much about how in practice very few vendors have a setup to detect if conflicting transactions were broadcast on the network simultaneously - after all if that is the case which transaction gets mined is up to

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Adam Back
On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote: If the commitment is opaque at the time of inclusion in the block then I will create multiple commitments and then after revealing the commitment and spend to you I will reveal the earlier commitment which commits the coins to an

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Adam Back
btw I posted some of this thread on the dev forum: https://bitcointalk.org/index.php?topic=206303.msg2157994#msg2157994 A related idea is occuring to me that maybe these committed transactions could actually as a side effect make bitcoin scale slightly better by reducing the p2p flood filled

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-16 Thread Adam Back
On Wed, May 15, 2013 at 07:45:34PM -0700, Gregory Maxwell wrote: [committed coins] depending on how its done, at most conceals the transactions from people who aren't a party to them... though as time goes on eventually everyone becomes a party to a sufficiently old coin, and avoiding publication

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-16 Thread Adam Back
More somewhat improved crypto stuff... On Thu, May 16, 2013 at 01:32:22PM +0200, Adam Back wrote: I suggested fixed size committed coin spends [...] (blind-sender, auth-tag, encrypted-tx-commit) (pub key P = xG, G = base point) blind-sender = cP (public key EC multiplied by constant c

Re: [Bitcoin-development] Decentralizing mining

2013-05-31 Thread Adam Back
I like this idea a lot. To add: I think it is a bug and security risk if pooled-solo or (current pooled miners) do not add randomness to their extraNonce2 (like 128-bits of it). For privacy and to avoid various hostile-pre-mining attacks it should be done this way. Lack of the self-chosen

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

2013-06-02 Thread Adam Back
So the idea is that people may want to use proof-of-work unrelated to bitcoin, and abuse bitcoin to obtain that proof, in a way denominated in BTC (and with a published USD exchange rate). And the ways they can do that are to: a) create unspendable addresses (which maybe you cant compact in the

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

2013-06-13 Thread Adam Back
for bitcoin, or an alt-coin. Adam On Sun, May 19, 2013 at 03:23:59PM +0200, 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

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

2013-06-14 Thread Adam Back
coinbase). Adam On Fri, Jun 14, 2013 at 03:20:58PM -0400, Peter Todd wrote: On Thu, Jun 13, 2013 at 03:39:32PM +0200, Adam Back wrote: I had one thought towards this which is a different kind of merged mining. I think a fair merged mining aiming for price parity would be done by the miner having

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

2013-06-19 Thread Adam Back
, 2013 at 05:28:15PM +0200, Adam Back wrote: [q-th root with unknown no discrete log artefact] If it was a concern I guess you could require a proof of knowledge of discrete log. ie as well as public key parent, multiplier the address must include ECDSA sig or Schnorr proof of knowledge (which both

[Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-05 Thread Adam Back
Hi I presume everyone saw the announce from Matthew Green Ian Miers at JHU on the release of libzerocoin: https://github.com/Zerocoin/libzerocoin So now that raises the question of how can people experiment with real money with zerocoin. I think its fair to summarize there is resistance to

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-13 Thread Adam Back
On Sat, Jul 13, 2013 at 11:51:14AM +0200, Jorge Timón wrote: I don't see the need to peg zerocoins to bitcoins. Without a bitcoin peg on the creation cost of zerocoins, it is hard for a new alt-coin to have a stable value. Bitcoin itself is volatile enough. Generally the available compute for

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Adam Back
I think bi-directional sacrifice is probably not needed to assure a close to 1:1 bi-directional peg. (Bi-directional sacrifice meaning also to convert a zerocoin to a bitcoin you sacrifice a zerocoin and bitcoin would be modified to accept a zerocoin sacrifice as a way to replace a previously

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

2013-09-29 Thread Adam Back
There are some policy decision points in the protocol (and code) that may become centralized risks or choke points that undermine the p2p nature. So the extent that those can be argued to have in principle have a technical fix, it could be quite interesting to research the necessary technology

[Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)

2013-10-01 Thread Adam Back
On Sun, Sep 29, 2013 at 10:49:00AM -0700, Mark Friedenbach wrote: This kind of thing - providing external audits of customer accounts without revealing private data - would be generally useful beyond taxation. If you have any solutions, I'd be interested to hear them (although bitcoin-dev is

Re: [Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)

2013-10-01 Thread Adam Back
01, 2013 at 04:26:03PM +0200, Adam Back wrote: On Sun, Sep 29, 2013 at 10:49:00AM -0700, Mark Friedenbach wrote: This kind of thing - providing external audits of customer accounts without revealing private data - would be generally useful beyond taxation. If you have any solutions, I'd

Re: [Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)

2013-10-07 Thread Adam Back
#msg3294618 Adam On Tue, Oct 01, 2013 at 09:11:43PM +0200, Adam Back wrote: Err actually not (efficient) I made a mistake that came out when I started writing it up about how the t parameter in the proof relates to bitcoin precision and coin representation (I thought t=2, but t=51). Damn! Back

[Bitcoin-development] two comments on brain-wallet security (and BIP 38)

2013-10-15 Thread Adam Back
So I had a go at deciphering BIP 038 in summary what I think its doing is (ommitting lot and sequence and deterinistic IVs for simplicity): user: x1 = Scrypt( salt=random, pass ) P = x1*G send (salt, P) to coin manufacturer - manufacturer:

Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-28 Thread Adam Back
I think its a mistake relying directly on X509, its subject to corrpution attacks, involves ASN.1 and enough openSSL X.500 encoding abiguity (or other code base) to be a security nightmare. Why not make the payment messages signed by bitcoin keys. If someone wants to associate with X.509 they

Re: [Bitcoin-development] Zeroconf-safe tx replacement (replace-for-fee)

2013-11-04 Thread Adam Back
Might leak less wiggle room and be simpler/more robut to validate that *everything* has to be the same except for the amount going to one (presumed change) address. A privacy leak I know, but dont do that - ie send enough change the first time. And network analysis has shown change addresses

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

2013-11-15 Thread Adam Back
While we're discussing the emotive (though actually of real relevance for bitcoin user comprehension and sentiment) I couldnt resisnt to add some trivia reference it is amusing that a currency rarely in history had to deflate (remove 0s) rather than inflate (add 0s). Viz this hyperinflated fifty

[Bitcoin-development] bitcoin 1.x 0.x in parallel (Re: is there a way to do bitcoin-staging?)

2013-11-21 Thread Adam Back
Yeah but that sounds pretty much like test-net and starts a new digital scarcity on an alpha-qa level network, with an implied promise that maybe if you're lucky your coins might survive the alpha testing and have some value. I'm not talking about some slightly stabler version of test-net.

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2014-01-03 Thread Adam Back
You know if you want to make some form of investment, you might like make an attempt to look them up on the internet, check the phone number in a phone book or directory enquiries, look for references and reviews? So it is with the hash of the binary you are about to trust with your investment

Re: [Bitcoin-development] An idea for alternative payment scheme

2014-01-03 Thread Adam Back
Seems like you (Nadav) are the third person to reinvent this idea so far :) I wrote up some of the post-Bytecoin variants here: https://bitcointalk.org/index.php?topic=317835.msg4103530#msg4103530 The general limitation so far is its not SPV compatible, so the recipient has to test each payment

Re: [Bitcoin-development] Payment protocol and reliable Payment messages

2014-01-14 Thread Adam Back
He's probably thinking of fair advertising rules. There are regulations motivated by consumer protection/advertising standards (prevents merchant listing attractive prices in media, and then when consumer goes to pay the merchant says oh actually that doesnt include X and Y, and the minimum price

Re: [Bitcoin-development] Stealth Addresses

2014-01-14 Thread Adam Back
I saw in the math version you had said Q'=Q+H(S) and I presumed it was a typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G and therefore that Util.SingleSHA256() multiplies by G internally? Adam

Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread Adam Back
Because the mnemonic is an encoding of a 128-bit random number using its hash as a private key (or derived part of one) is not a problem, its just an alternate alphabet encoding of the random private key. Not being able to generically understand the checksum. Seems tricky to solve other than say

Re: [Bitcoin-development] Bait for reusable addresses

2014-01-24 Thread Adam Back
I think prefix has analysis side effects. There are (at least) 4 things that link payments: the graph of payment flows, timing, precise amounts, IP addresses, but with prefix a 5th: the prefix allows public elmination of candidates connections, I think that may make network flow analysis even

[Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses)

2014-01-25 Thread Adam Back
widely used hardness assumptions. Adam (*) analogous to the way IBE is used as a building block for Non-Interactive Forward Secrecy (NIFS) On Fri, Jan 24, 2014 at 11:13:30AM -0500, Peter Todd wrote: On Fri, Jan 24, 2014 at 04:42:35PM +0100, Adam Back wrote: Now while it would be clearly a very nice

Re: [Bitcoin-development] (space) efficient reusable addr via weil pairing IBE (Re: Bait for reusable addresses)

2014-02-02 Thread Adam Back
I think you Peter Jeremy figured it out - dont disagree with the explanation details. And it seems better explained between the two posts than I did. I think Peter is right that you do not need an explicit prefix, the prefix after decryption can be a chosen number of leading 0s and this gives a

Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)

2014-03-08 Thread Adam Back
Also the other limitation for ECDSA is that there is no known protocol to create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without either a sending its private key to b or viceversa (or both to a third party). With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a

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

2014-03-16 Thread Adam Back
, 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 versions. Development runs in parallel

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-21 Thread Adam Back
ECDSA. Adam On Fri, Mar 21, 2014 at 11:25:59AM +0100, Andreas Schildbach wrote: On 03/20/2014 01:12 PM, Adam Back wrote: Whats a sensible limit on practical/convenient QR code size? Technically 3 KB. In my experience codes above 1.5 KB become impossible to scan (ZXing scanner, 3 years ago

Re: [Bitcoin-development] Payment Protocol for Face-to-face Payments

2014-03-21 Thread Adam Back
According to Bernstein it's patent FUD (expired, ancient and solid prior art). http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html Adam On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote: Oh, one other reason I found - apparently RIM, at least in the past,

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

2014-04-16 Thread Adam Back
Big picture/mid-term I think air-gaps and zero-trust ecosystem components are the only solution. (zero-trust meaning like real-time auditability, or type 2/type 3 exchanges based on atomic-swap, trustless escrow etc). Need a mass-production and air-drop of trezors :) There is one more problem

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

2014-04-16 Thread Adam Back
Not to get snarky or OS elitist but as I understand it windows security, even during its support period has been measured in low digit number of days in the year when is NOT an outstanding known remote root compromise or combination of remote user compromise + priviledge escalation. Add in

Re: [Bitcoin-development] Bitcoin Protocol Specification

2014-05-18 Thread Adam Back
Suggestion: maybe you want to write and post here a paragraph summarizing the topic of your paper so people can know if they feel qualified and if they need to review it from their interests. Adam On Sun, May 18, 2014 at 03:35:33PM +0200, Krzysztof Okupski wrote: Dear all, I'd like to kindly

[Bitcoin-development] patents...

2014-05-19 Thread Adam Back
someone recently wrote (not pointing fingers, nor demanding a spirited defense from that person, its a generic comment): PS: the device has patents pending btw about patents, I wonder if people who feel the need to do that, would you consider putting those patents into like a linux foundation

[Bitcoin-development] good bitcoin summary paper in more detail than Satoshi paper (Re: Bitcoin Protocol Specification)

2014-05-20 Thread Adam Back
, concise presentation of many bitcoin details that are otherwise hard to put together, requiring examining source or asking people knowledgeable at algorithm/code level. http://enetium.com/resources/Bitcoin.pdf Adam On Sun, May 18, 2014 at 04:38:53PM +0200, Adam Back wrote: Suggestion: maybe you

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-09 Thread Adam Back
I think you can do everything with the existing script level nlocktime in some kind of turing completeness sense (maybe); but there is a complexity cost that often you have to resort to extra dependent transaction(s) (and work-around malleability until that is fully fixed) just to get the effect.

Re: [Bitcoin-development] BIP process

2014-10-15 Thread Adam Back
please not google groups *, I'd vote for sourceforge or other simple open list software over google groups. Adam * 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

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

2014-10-22 Thread Adam Back
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 Adam On 16 March 2014 15:58, Adam Back a...@cypherspace.org wrote: So

Re: [Bitcoin-development] death by halving

2014-10-25 Thread Adam Back
Some thoughts about Alex's analysis: - bitcoin price may increase (though doubling immediately might be unlikely) after the halving (because the new coins are in short supply). Apparently there is some evidence of a feedback loop between number of freshly mined coins sold to cover electrical

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Adam Back
It seems to me that people maybe arriving at the idea that they should put transaction data in the blockchain for three related reasons: a) its there and its convenient; and b) they are thinking about permanent storage and being able to recover from backup using a master seed to a bip32

Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

2014-12-21 Thread Adam Back
On 20 December 2014 at 14:48, Peter Todd p...@petertodd.org wrote: We need the following primitives operating on message m, pubkey p, and a valid signature sig1 for m, p: AntiReplaySign(m, p, sig1) - sig2 VerifyAntiReplaySig(m, p, sig2) - True or False Additionally once

[Bitcoin-development] one-show signatures (Re: The relationship between Proof-of-Publication and Anti-Replay Oracles)

2014-12-21 Thread Adam Back
Yes you could for example define a new rule that two signatures (double-spend) authorises something - eg miners to take funds. (And this would work with existing ECDSA addresses unrestricted R-value choices). I wasnt really making a point other than an aside that it maybe is sort-of possible to

Re: [Bitcoin-development] The relationship between Proof-of-Publication and Anti-Replay Oracles

2014-12-22 Thread Adam Back
(Again nothing new to say here, just putting my notes in this discussion, where I started with an earlier discussion that Peter wrote up with a subject of disentangling blockchain design). In the discussion last year that started the analysis of disentangling blockchain design I had broken out

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-14 Thread Adam Back
Strongly with Peter on this. That its highly complex to maintain strict consensus between bitcoin versions, does not justify consensus rewrite experiments; it tells you that the risk is exponentially worse and people should use and rally around libconsensus. I would advise any bitcoin ecosystem

[Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Adam Back
I agree with Mike Jeff. Blowing up 0-confirm transactions is vandalism. bitcoin transactions are all probabilistic. there is a small chance 1-confirm transactions can be reversed, and a different but also usable chance that 0-confirm transactions can be reversed. I know 0-confirm is

[Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Adam Back
I saw there was some discussion on this topic on the bitcoinj list. (I dont think I can post there without subscribing probably.) Someone had posted about the lack of privacy provision from the current implementation parameters and real-world factors similar to described in this academic paper

Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Adam Back
Mike Hearn wrote: Adam Back wrote: Its seems surprising no one thought of it that way before (as it seems obvious when you hear it) but that seems to address the privacy issues as the user can fetch the block bloom filters and then scan it in complete privacy. And then what? So you know

Re: [Bitcoin-development] bloom filtering, privacy

2015-02-20 Thread Adam Back
The idea is not mine, some random guy appeared in #bitcoin-wizards one day and said something about it, and lots of people reacted, wow why didnt we think about that before. It goes something like each block contains a commitment to a bloom filter that has all of the addresses in the block stored

Re: [Bitcoin-development] bloom filtering, privacy

2015-02-21 Thread Adam Back
If you want to be constructive and index transactions that are not p2sh but non-simple and contain checksig so the address is visible, you could do that with a block bloom filter also. I wasnt sure if the comments about the need to batch requests was about downloading headers filters, or about

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Adam Back
its an always offline node, so it knows nothing really other than a BIP 32 hierarchy of keys a signature request. So the signature request has to drag with it information to validate what the value is, in order to be sure not to sign away 99% to fees. Signing the transaction value and having the

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Adam Back
+/- etc. might be an interesting thing to explore as a place to store live versions of hard fork wishlist items where people who need them early can help validate them. I am not sure that helps the full network upgrade issue though. Adam On 23 January 2015 at 16:12, Adam Back

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Adam Back
Well this is all very extreme circumstances, and you'd have to assume no rational player with an interest in bitcoin would go there, but to play your analysis forward: users are also not powerless at the extreme: they could change the hash function rendering current deployed ASICs useless in

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

2015-05-12 Thread Adam Back
I think its fair to say no one knows how to make a consensus that works in a decentralised fashion that doesnt weaken the bitcoin security model without proof-of-work for now. I am presuming Gavin is just saying in the context of not pre-judging the future that maybe in the far future another

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

2015-06-14 Thread Adam Back
It might be as well to keep the archive but disable new posts as otherwise we create bit-rot for people who linked to posts on sourceforge. The list is also archived on mail-archive though. https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ Adam On 14 June 2015 at 22:55,

[Bitcoin-development] comments on BIP 100

2015-06-14 Thread Adam Back
Hi I made these comments elsewhere, but I think really we should be having these kind of conversations here rather than scattered around. These are about Jeff Garzik's outline draft BIP 100 I guess this is the latest draft: (One good thing about getting off SF would be finally JGarzik's emails

[Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork

2015-06-14 Thread Adam Back
Mike Hearn m...@plan99.net wrote: Which is why there will soon be a fork that does it. I understand why you would be keen to scale bitcoin, everyone here is. But as you seem to be saying that you will do a unilateral hard-fork, and fork the code-base simultaneously, probably a number of people

Re: [Bitcoin-development] comments on BIP 100

2015-06-15 Thread Adam Back
I think he's more talking about like extension-blocks, however they are actually soft-forkable even (and keep the 21m coins obviously) See See https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07937.html and Tier Nolan tech detail

Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork

2015-06-15 Thread Adam Back
Hi Mike Well thank you for replying openly on this topic, its helpful. I apologise in advance if this gets quite to the point and at times blunt, but transparency is important, and we owe it to the users who see Bitcoin as the start of a new future and the$3b of invested funds and $600m of VC

[Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Adam Back
Hi Gavin Sorry for slow response broken threading - mailbox filled up only saw your response on archive. I do earnestly think opt-in block-size increases are politically cleaner (gives different people different sized blocks by their own volition without forcing a compromise) and less risky

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Adam Back
Mike wrote: Businesses who are keen to have more transactions, would make it their problem to implement in their wallet, or ask the wallet vendor/maintainer they're working with to do it. Nothing breaks if they dont use it. I don't see how this is the case. If an exchange supports

Re: [Bitcoin-development] Fwd: Block Size Increase Requirements

2015-06-01 Thread Adam Back
So lets rephrase that and say instead more correctly it is the job of miners (collectively) to be well connected globally - and indeed there are incentivised to be or they tend to receive blocks at higher latency and so are at increased risk of orphans. And miner groups with good block latency

[Bitcoin-development] soft-fork block size increase (extension blocks) Re: Proposed alternatives to the 20MB stepfunction

2015-05-29 Thread Adam Back
I discussed the extension block idea on wizards a while back and it is a way to soft-fork an opt-in block-size increase. Like everything here there are pros and cons. The security is better than Raylstonn inferred from Tier's explanation I think.. It works as Tier described - there is an

Re: [Bitcoin-development] [BIP draft] Consensus-enforced transaction replacement signalled via sequence numbers

2015-06-02 Thread Adam Back
That would also introduce the anomaly of a script that was once valid becoming later invalid, when nothing varies other than time. That is not super compatible with the current model of reprocessing transactions in later blocks if the block they were first in gets reorged. (Not a huge

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

2015-05-26 Thread Adam Back
The general idea for replace by fee is that it would be restricted so as to make it safe, eg all the original addresses should receive no less bitcoin (more addresses can be added). The scorched earth game theory stuff (allowing removing recipients) is kind of orthogonal. Adam On 26 May 2015 at

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

2015-05-26 Thread Adam Back
Well so for example it could have an additional input (to increase the BTC paid into the transaction) and pay more to an existing change address and higher fee, or add an additional change address, and leave a larger fee, or if you had a right-sized coin add an additional input that all goes to

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

2015-05-26 Thread Adam Back
I think the point is the replacement tx spends the same inputs (plus additional inputs), so if the original tx is accepted, and your replacement rejected, thats good news - you dont have to pay the higher fee, the extra input remains unspent (and can be used later for other purpose) and the extra

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

2015-06-19 Thread Dr Adam Back
to misinterpretation so to clarify: On 19 June 2015 at 11:22, Dr Adam Back a...@cypherspace.org wrote: For example it could hypothetically allow 10MB blocks on one chain and 100kB blocks on the main chain. People say complexity, scary. Sure I am talking longer term, but we have to also make concrete

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

2015-06-19 Thread Dr Adam Back
Nicely put Eric. Relatedly my initial experience with Bitcoin in trying to improve bitcoin in fungibility, privacy decentralisation, I found some interesting things, like Confidential Transactions (that Greg Maxwell has now optimised via a new generalisation of the hash-ring signature construct