Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Mark Friedenbach
What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe. On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson andr...@petersson.at wrote: I have

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

2015-06-18 Thread Mark Friedenbach
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn m...@plan99.net wrote: The first issue is how are decisions made in Bitcoin Core? I struggle to explain this to others because I don't understand it myself. Is it a vote of people with commit access? Is it a 100% agreement of core developers and if

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

2015-06-18 Thread Mark Friedenbach
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com wrote: The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. To do that, you need to (a) plan forward, in order to (b) set a hard fork date in

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

2015-06-18 Thread Mark Friedenbach
Matt, I for one do not think that the block size limit should be raised at this time. Matt Corallo also started the public conversation over this issue on the mailing list by stating that he was not in favor of acting now to raise the block size limit. I find it a reasonable position to take that

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-12 Thread Mark Friedenbach
Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their own blocks, or conforming incentives among voters by opting to be with the (slight) majority in order to minimize fees. Wouldn't it

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

2015-06-06 Thread Mark Friedenbach
Certainly, but I would drop discussion of IsStandard or consensus rules. On Jun 6, 2015 1:24 AM, Wladimir J. van der Laan laa...@gmail.com wrote: On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote: Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

2015-06-05 Thread Mark Friedenbach
Rusty, this doesn't play well with SIGHASH_SINGLE which is used in assurance contracts among other things. Sometimes the ordering is set by the signing logic itself... On Jun 5, 2015 9:43 PM, Rusty Russell ru...@rustcorp.com.au wrote: Title: Canonical Input and Output Ordering Author: Rusty

Re: [Bitcoin-development] Tough questions for Peter Todd, Chief Scientist {Mastercoin | Counterparty | Coinkite | Darkwallet | Viacoin}

2015-06-04 Thread Mark Friedenbach
Why is this your business or the business of anyone on this list? Take it somewhere else. On Thu, Jun 4, 2015 at 2:52 PM, Sven Berg svenb...@airmail.cc wrote: 1) Hours/week have you devoted to each project out of a 40hr work week 2) Upfront and ongoing fees for use of your name 3) Break

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

2015-06-02 Thread Mark Friedenbach
, at 12:16 AM, Mark Friedenbach m...@friedenbach.org wrote: You are correct! I am maintaining a 'checksequenceverify' branch in my git repository as well, an OP_RCLTV using sequence numbers: https://github.com/maaku/bitcoin/tree/checksequenceverify Most of the interesting use cases

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

2015-06-01 Thread Mark Friedenbach
The reference implementation is available at the following git repository: https://github.com/maaku/bitcoin/tree/sequencenumbers I request that the BIP editor please assign a BIP number for this work. Sincerely, Mark Friedenbach

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

2015-06-01 Thread Mark Friedenbach
space, and would likely work for most cases where an OP_RCLTV would be needed. Best, Stephen On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach m...@friedenbach.org wrote: I have written a reference implementation and BIP draft for a soft-fork change to the consensus-enforced behaviour

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

2015-05-27 Thread Mark Friedenbach
On Wed, May 27, 2015 at 3:11 AM, Mike Hearn m...@plan99.net wrote: As I believe out of all proposed protocols Satoshi's is still the most powerful, I would suggest that any change to the semantics on nSequence be gated by a high bit or something, so the original meaning remains available

[Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

2015-05-26 Thread Mark Friedenbach
Sequence numbers appear to have been originally intended as a mechanism for transaction replacement within the context of multi-party transaction construction, e.g. a micropayment channel. The idea is that a participant can sign successive versions of a transaction, each time incrementing the

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

2015-05-26 Thread Mark Friedenbach
Please let's at least have some civility and decorum on this list. On Tue, May 26, 2015 at 1:30 PM, joli...@airmail.cc wrote: You're the Chief Scientist of __ViaCoin__ a alt with 30 second blocks and you have big banks as clients. Shit like replace-by-fee and leading the anti-scaling mob is

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-10 Thread Mark Friedenbach
wrote: Le 08/05/2015 22:33, Mark Friedenbach a écrit : * For each block, the miner is allowed to select a different difficulty (nBits) within a certain range, e.g. +/- 25% of the expected difficulty, and this miner-selected difficulty is used for the proof of work check. In addition

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-10 Thread Mark Friedenbach
Micropayment channels are not pie in the sky proposals. They work today on Bitcoin as it is deployed without any changes. People just need to start using them. On May 10, 2015 11:03, Owen Gunden ogun...@phauna.org wrote: On 05/08/2015 11:36 PM, Gregory Maxwell wrote: Another related point

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Mark Friedenbach
constrains the maximum allowed block size to be within a range supported by fees on the network, providing an emergency relief valve that we can be assured will only be used at significant cost. Mark Friedenbach * There has over time been various discussions on the bitcointalk forums about dynamically

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Mark Friedenbach
Transactions don't expire. But if the wallet is online, it can periodically choose to release an already created transaction with a higher fee. This requires replace-by-fee to be sufficiently deployed, however. On Fri, May 8, 2015 at 1:38 PM, Raystonn . rayst...@hotmail.com wrote: I have a

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Mark Friedenbach
On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine vois...@gmail.com wrote: This is a clever way to tie block size to fees. I would just like to point out though that it still fundamentally is using hard block size limits to enforce scarcity. Transactions with below market fees will hang in limbo

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-08 Thread Mark Friedenbach
resorting to dropping transactions after a prolonged delay. Aaron Voisine co-founder and CEO breadwallet.com On Fri, May 8, 2015 at 3:45 PM, Mark Friedenbach m...@friedenbach.org wrote: On Fri, May 8, 2015 at 3:43 PM, Aaron Voisine vois...@gmail.com wrote: This is a clever way to tie

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Mark Friedenbach
The problems with that are larger than time being unreliable. It is no longer reorg-safe as transactions can expire in the course of a reorg and any transaction built on the now expired transaction is invalidated. On Fri, May 8, 2015 at 1:51 PM, Raystonn rayst...@hotmail.com wrote: Replace by

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

2015-04-16 Thread Mark Friedenbach
At this moment anyone can alter the txid. Assume transactions are 100% malleable. On Apr 16, 2015 9:13 AM, s7r s...@sky-ip.org wrote: Hi Pieter, Thanks for your reply. I agree. Allen has a good point in the previous email too, so the suggestion might not fix anything and complicate things.

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-21 Thread Mark Friedenbach
Thank you Jorge for the contribution of the Stag Hunt terminology. It is much better than a politically charged scorched earth. On Feb 21, 2015 11:10 AM, Jorge Timón jti...@jtimon.cc wrote: I agree scorched hearth is a really bad name for the 0 conf protocol based on game theory. I would have

Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

2014-08-11 Thread Mark Friedenbach
There should not be a requirement at this level to ensure validity. That would too constrain use cases of implementations of your protocol. It is not difficult to imagine use cases where parties generate chained transactions on top of unconfimed transactions. Although malleability currently makes

Re: [Bitcoin-development] CoinShuffle: decentralized CoinJoin without trusted third parties

2014-08-09 Thread Mark Friedenbach
On Sat, Aug 9, 2014 at 6:10 AM, Sergio Lerner sergioler...@certimix.com wrote: Hi Tim, It's clear from the paper that the second party in the protocol can de-anonymize the first party. So it's seems that dishonest shufflers would prefer to be in that position in the queue. That's not

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Mark Friedenbach
On 08/06/2014 11:42 AM, Peter Todd wrote: On 6 August 2014 08:17:02 GMT-07:00, Christian Decker decker.christ...@gmail.com wrote: +1 for the new field, overloading fields with new meaning is definitely not a good idea. To add a new field the best way to do it is create a new, parallel, tx

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Mark Friedenbach
On 08/06/2014 01:02 PM, Tom Harding wrote: With first-eligible-height and last-eligible-height, creator could choose a lifetime shorter than the max, and in addition, lock the whole thing until some point in the future. Note that this would be a massive, *massive* change that would completely

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Mark Friedenbach
On 08/06/2014 01:20 PM, Peter Todd wrote: The general case doesn't require transmission of any merkle data; it is derived from the tx data. How can that possibly be the case? The information is hidden behind the Merkle root in the transaction. The validator needs to know whether there is an

Re: [Bitcoin-development] Mining Hashrate Caps

2014-07-17 Thread Mark Friedenbach
Can someone explain to these guys and the public why promising to limit yourselves to *only* a 50% chance of successfully double-spending a 6 confirm transaction is still not acceptable? q=0.4 z=0 P=1 z=1 P=0.828861 z=2 P=0.736403 z=3 P=0.664168 z=4 P=0.603401 z=5

Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

2014-06-19 Thread Mark Friedenbach
Sergio, why is preventing mining pools a good thing? The issue is not mining pools, which provide a needed service in greatly reducing variance beyond what any proposal like this can do. The issue is centralized transaction selection policies, which is entirely orthogonal. And the solution

Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

2014-06-19 Thread Mark Friedenbach
Do you need to do full validation? There's an economic cost to mining invalid blocks, and even if that were acceptable there's really no reason to perform such an attack. The result would be similar to a block withholding attack, but unlike block withholding it would be trivially detectable

Re: [Bitcoin-development] Fidelity bonds for decentralized instant confirmation guarantees

2014-06-17 Thread Mark Friedenbach
Not with current script, but there are mechanisms by which you can do a digital signature where signing two pieces of information reveals the ECDSA k parameter, thereby allowing anyone to recover the private key and steal the coins. Practically speaking, these are not very safe systems to use.

Re: [Bitcoin-development] Future Feature Proposal - getgist

2014-06-05 Thread Mark Friedenbach
The correct approach here is header hash-tree commitments which enable compact (logarithmic) SPV proofs that elide nearly all intervening headers since the last checkpoint. You could then query the hash tree for references to any of the headers you actually need. See this message for details:

Re: [Bitcoin-development] PSA: Please sign your git commits

2014-05-23 Thread Mark Friedenbach
I know the likelihood of this happening is slim, but if these are the desired features we should consider switching to monotone (monotone.ca) which has a much more flexible DAG structure and workflow built around programmable multi-sig signing of commits. We could still maintain the github account

Re: [Bitcoin-development] PSA: Please sign your git commits

2014-05-21 Thread Mark Friedenbach
On 05/21/2014 10:10 AM, Wladimir wrote: On Wed, May 21, 2014 at 6:39 PM, Chris Beams ch...@beams.io wrote: I'm personally happy to comply with this for any future commits, but wonder if you've considered the arguments against commit signing [1]? Note especially the reference therein to Linus'

Re: [Bitcoin-development] Bug with handing of OP_RETURN?

2014-05-03 Thread Mark Friedenbach
I don't think such a pull request would be accepted. The point was to minimize impact to the block chain. Each extras txout adds 9 bytes minimum, with zero benefit over serializing the data together in a single OP_RETURN. On 05/03/2014 11:39 AM, Peter Todd wrote: The standard format ended up

Re: [Bitcoin-development] Bug with handing of OP_RETURN?

2014-05-03 Thread Mark Friedenbach
Is it more complex? The current implementation using template matching seems more complex than `if script.vch[0] == OP_RETURN script.vch.size() 42` On 05/03/2014 12:08 PM, Gregory Maxwell wrote: On Sat, May 3, 2014 at 11:55 AM, Mark Friedenbach m...@monetize.io wrote: I don't think

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-28 Thread Mark Friedenbach
On 04/28/2014 07:32 AM, Sergio Lerner wrote: So you agree that: you need a periodic connection to a honest node, but during an attack you may loose that connection. This is the assumption we should be working on, and my use case (described in

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-27 Thread Mark Friedenbach
I would prefer to avoid. By using back-links you make it have log(N) space usage. On 04/26/2014 07:39 PM, Sergio Lerner wrote: El 26/04/2014 10:43 p.m., Mark Friedenbach escribió: Sergio, First of all, let's define what an SPV proof is: it is a succinct sequence of bits which can

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

2014-04-27 Thread Mark Friedenbach
I'm not convinced of the necessity of this idea in general, but if it were to be implemented I would recommend serializing the nVersion field as a VarInt (Pieter Wuille's multi-byte serialization format) and using the remaining space of the 4 bytes as your extra nonce. That would allow

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-27 Thread Mark Friedenbach
On 04/27/2014 05:36 AM, Sergio Lerner wrote: Without invoking moon math or assumptions of honest peers and jamming-free networks, the only way to know a chain is valid is to witness the each and every block. SPV nodes on the other hand, simply trust that the most-work chain is a valid

Re: [Bitcoin-development] BIP - Selector Script

2014-04-26 Thread Mark Friedenbach
I think you're misunderstanding the point. The way you get IsStandard changed is that you make an application-oriented BIP detailing the use of some new standard transaction type (say, generalized hash-locked transactions for atomic swaps). We then discuss that proposal for its technical merits

Re: [Bitcoin-development] Proof-of-Stake branch?

2014-04-26 Thread Mark Friedenbach
There's no need to be confrontational. I don't think anyone here objects to the basic concept of proof-of-stake. Some people, myself included, have proposed protocols which involve some sort of proof of stake mechanism, and the idea itself originated as a mechanism for eliminating checkpoints,

Re: [Bitcoin-development] Proof-of-Stake branch?

2014-04-26 Thread Mark Friedenbach
remember who I saw discussing this idea. Might have been Vitalik Buterin? On 27 April 2014 6:39:28 AM AEST, Mark Friedenbach m...@monetize.io wrote: There's no need to be confrontational. I don't think anyone here objects to the basic concept of proof-of-stake. Some people, myself included

Re: [Bitcoin-development] About Compact SPV proofs via block header commitments

2014-04-26 Thread Mark Friedenbach
Sergio, First of all, let's define what an SPV proof is: it is a succinct sequence of bits which can be transmitted as part of a non-interactive protocol that convincingly establishes for a client without access to the block chain that for some block B, B has an ancestor A at some specified

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-04-22 Thread Mark Friedenbach
Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin. Unfortunately few of the alts ever figured this out. On 04/22/2014 01:39 AM, Tamas Blummer wrote: Extra encoding for testnet is quite useless complexity in face of many alt chains. BIPS should be chain agnostic. Regards,

Re: [Bitcoin-development] Economics of information propagation

2014-04-21 Thread Mark Friedenbach
That wasn't what I was saying. Right now the primacy of a block is determined by the time at which the `block` message is received, which is delays due to both the time it takes to transmit the block data and the time it takes to validate. Headers-first, on the other hand, has the option of basing

Re: [Bitcoin-development] Economics of information propagation

2014-04-20 Thread Mark Friedenbach
As soon as we switch to headers first - which will be soon - there will be no difference in propagation time no matter how large the block is. Only 80 bites will be required to propagate the block header which establishes priority for when the block is fully validated. On Apr 20, 2014 6:56 PM,

Re: [Bitcoin-development] Timed testing

2014-04-17 Thread Mark Friedenbach
Not necessarily. Running a private server involves listening to the p2p network for incoming transactions, performing validation on receipt and organizing a mempool, performing transaction selection, and relaying blocks to auditors - none of which is tested in a reindex. A reindex would give you

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

2014-04-16 Thread Mark Friedenbach
XP is no longer receiving security patches from Microsoft, and hasn't been for some time. There are known remote exploits that aren't going to be fixed, ever. On Apr 16, 2014 8:15 AM, Kevin kevinsisco61...@gmail.com wrote: On 4/16/2014 4:14 AM, Wladimir wrote: Hello, Today I noticed that

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

2014-04-16 Thread Mark Friedenbach
On 04/16/2014 09:27 AM, Kevin wrote: Should we then add an alert message to wallet installers such as, Such and such will not run on windows xp? It's not really our place to police that ... plus it's perfectly safe to be running Bitcoin Core as a full node on XP. It's just the wallet

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

2014-04-16 Thread Mark Friedenbach
platform that the original vendor (MS) no longer supports themselves. On Apr 16, 2014, at 9:35 AM, Mark Friedenbach m...@monetize.io wrote: On 04/16/2014 09:27 AM, Kevin wrote: Should we then add an alert message to wallet installers such as, Such and such will not run on windows xp? It's

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

2014-04-16 Thread Mark Friedenbach
On 04/16/2014 02:29 PM, Kevin wrote: Okay, so how about an autoupdate function which pulls a work around off the server? Sooner or later, the vulnerabilities must be faced. NO. Bitcoin Core will never have an auto-update functionality. That would be a single point of failure whose compromise

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Mark Friedenbach
You took the quote out of context: a full node can copy the chain state from someone else, and check that its hash matches what the block chain commits to. It's important to note that this is a strict reduction in security: we're now trusting that the longest chain (with most proof of work)

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Mark Friedenbach
Checkpoints will go away, eventually. On 04/10/2014 02:34 PM, Jesus Cea wrote: On 10/04/14 18:59, Pieter Wuille wrote: It's important to note that this is a strict reduction in security: we're now trusting that the longest chain (with most proof of work) commits to a valid UTXO set (at some

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Mark Friedenbach
On 04/09/2014 09:09 AM, Tamas Blummer wrote: Yes, SPV is a sufficient API to a trusted node to build sophisticated features not offered by the core. SPV clients of the border router will build their own archive and indices based on their interest of the chain therefore the border router core

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Mark Friedenbach
I've advocated for this in the past, and reasonable counter-arguments I was presented with are: (1) bittorrent is horribly insecure - it would be easy to DoS the initial block download if that were the goal, and (2) there's a reasonable pathway to doing this all in-protocol, so there's no reason

Re: [Bitcoin-development] Feedback request: colored coins protocol

2014-04-07 Thread Mark Friedenbach
Flavien, capital is wealth or resources available for the stated purpose of the company. These bitcoins represent nothing more than a speculative floor owned by the investors, not the company. On 04/07/2014 07:00 AM, Flavien Charlon wrote: Jorge, they'd have to be. Otherwise, assuming the price

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mark Friedenbach
Right now running a full-node on my home DSL connection (1Mbps) makes other internet activity periodically unresponsive. I think we've already hit a point where resource requirements are pushing out casual users, although of course we can't be certain that accounts for all lost nodes. On

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mark Friedenbach
On 04/07/2014 09:57 AM, Gregory Maxwell wrote: That is an implementation issue— mostly one that arises as an indirect consequence of not having headers first and the parallel fetch, not a requirements issue. Oh, absolutely. But the question why are people not running full nodes? has to do with

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mark Friedenbach
On 04/07/2014 12:00 PM, Tamas Blummer wrote: Once a single transaction in pruned in a block, the block is no longer eligible to be served to other nodes. Which transactions are pruned can be rather custom e.g. even depending on the wallet(s) of the node, therefore I guess it is more handy to

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Mark Friedenbach
On 04/07/2014 12:20 PM, Tamas Blummer wrote: Validation has to be sequantial, but that step can be deferred until the blocks before a point are loaded and continous. And how do you find those blocks? I have a suggestion: have nodes advertise which range of full blocks they possess, then you

Re: [Bitcoin-development] Best practices for dust remining

2014-03-29 Thread Mark Friedenbach
NONE|ANYONECANPAY. This is what dust-be-gone does. On Mar 29, 2014 12:46 PM, Justus Ranvier justusranv...@gmail.com wrote: Suppose am m-of-n multisig wallet receives a bunch of dust deposits due to somebody advertising the Olympics, or any other reason, and the users of the wallet don't want

Re: [Bitcoin-development] Tree-chains preliminary summary

2014-03-25 Thread Mark Friedenbach
I'm afraid I'm going to be the jerk that requested more details and then only nitpicks seemingly minor points in your introduction. But its because I need more time to digest the contents of your proposal. Until then: But moving value between chains is inconvenient; right now moving value

Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

2014-03-24 Thread Mark Friedenbach
On 03/24/2014 01:34 PM, Troy Benjegerdes wrote: I'm here because I want to sell corn for bitcoin, and I believe it will be more profitable for me to do that with a bitcoin-blockchain-based system in which I have the capability to audit the code that executes the trade. A discussion over such a

Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

2014-03-23 Thread Mark Friedenbach
This isn't distributed-systems-development, it is bitcoin-development. Discussion over chain parameters is a fine thing to have among people who are interested in that sort of thing. But not here. On 03/23/2014 04:17 PM, Troy Benjegerdes wrote: I find it very irresponsible for Bitcoiners to on

Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

2014-03-22 Thread Mark Friedenbach
Please, by all means: ignore our well-reasoned arguments about externalized storage and validation cost and alternative solutions. Please re-discover how proof of publication doesn't require burdening the network with silly extra data that must be transmitted, kept, and validated from now until

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

2014-03-22 Thread Mark Friedenbach
Jeff, there are *plenty* of places that lack local Internet access for one or both participants. Obviously making the case where both participants lack access to the bitcoin network is difficult to secure, but not impossible (e.g. use a telephany-based system to connect to a centralized

[Bitcoin-development] Compact SPV proofs via block header commitments

2014-03-17 Thread Mark Friedenbach
Timon, and Mark Friedenbach. It is believed that the first explanation of this general idea is due to Andrew Miller in his 7 Aug 2012 forum post titled The High-Value-Hash Highway[2]. [1]http://sourceforge.net/p/bitcoin/mailman/message/32108143/ [2]https://bitcointalk.org/index.php?topic=98986.0

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

2014-03-14 Thread Mark Friedenbach
A cup of coffee in Tokyo costs about 55 yen. You see similar magnitude numbers in both Chinas, Thailand, and other economically important East Asian countries. Expect to pay hundreds of rupees in India, or thousands of rupees in Indonesia. This concept that money should have low, single digits

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

2014-03-13 Thread Mark Friedenbach
This ship may have already sailed, but... Using milli- and micro- notation for currency units is also not very well supported. Last time this thread was active, I believe there was a suggestion to use 1 XBT == 1 uBTC. This would bring us completely within the realm of supported behavior in

Re: [Bitcoin-development] Decentralized digital asset exchange with honest pricing and market depth

2014-03-01 Thread Mark Friedenbach
Only if you view bitcoin as no more than a payment network. On Mar 1, 2014 10:24 AM, Jeff Garzik jgar...@bitpay.com wrote: This is wandering far off-topic for this mailing list. On Sat, Mar 1, 2014 at 12:45 PM, Troy Benjegerdes ho...@hozed.org wrote: You can make the same argument against

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

2014-02-28 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Transaction fees are a DoS mitigating cost to the person making the transaction, but they are generally not paid to the people who actually incur costs in validating the blockchain. Actual transaction processing costs are an externality that is

[Bitcoin-development] Base-32 error correction coding

2014-02-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What follows is a proposed BIP for human-friendly base-32 serialization with error correction encoding. A formatted version is viewable as part of a gist with related code: https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki An

Re: [Bitcoin-development] working with the blockchain: transaction fees sum(inputs) != sum(outputs) (newbie questions)

2014-02-14 Thread Mark Friedenbach
) On Fri, Feb 14, 2014 at 5:42 PM, Mark Friedenbach m...@monetize.io mailto:m...@monetize.io wrote: On 02/14/2014 04:20 AM, Denis Andrejew wrote: What I'm trying to do is read the blockchain in order to find all unspent outputs. I'm using bitcoind via rpc as my source of information about

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Mark Friedenbach
On 02/12/2014 08:44 AM, Alan Reiner wrote: Changing the protocol to use these static IDs is a pretty fundamental change that would never happen in Bitcoin. But they can still be useful at the application level to mitigate these issues. Not to mention that it would be potentially very

Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since you are taking the hash of Unicode data, I would strongly recommend using a canonical form, e.g. Normalized Form C. On 01/20/2014 09:42 AM, slush wrote: Hi all, during recent months we've reconsidered all comments which we received from

Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Proper Unicode handling is a serious issue however. You don't want someone to move from one input method / machine to another and suddenly find that their coins are inaccessible, because of an issue of decomposed vs. compatibility forms or whatever.

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

2014-01-18 Thread Mark Friedenbach
On 01/18/2014 03:05 AM, Wladimir wrote: On Sat, Jan 18, 2014 at 9:11 AM, Odinn Cyberguerrilla ABISprotocol hat: on regarding: stuff not getting into blockchain in a day's time, microdonations not facilitated as much as they could be, Please point to your pull requests

Re: [Bitcoin-development] Stealth Addresses

2014-01-17 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/17/2014 01:15 AM, Mike Hearn 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 Too close

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

2014-01-17 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 CPFP is *extremely* important. People have lost money because this feature is missing. I think it's critical that it makes it into 0.9 If I get a low-priority donation from a blockchain.info wallet, that money can disappear if it doesn't make it into

Re: [Bitcoin-development] Stealth Addresses

2014-01-15 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/15/2014 04:05 PM, Jeremy Spilman wrote: Might I propose reusable address. Say it like it is. This is the only suggestion so far that I really like. No amount of finger wagging got people to stop using the block chain for data storage, but

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

2014-01-07 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/2014 10:31 PM, Thomas Voegtlin wrote: You are right. The 256-way branching follows from the fact that the tree was implemented using a key-value database operating with byte strings (leveldb). With this implementation constraint, a

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

2014-01-06 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/06/2014 10:13 AM, Peter Todd wrote: On Sun, Jan 05, 2014 at 07:43:58PM +0100, Thomas Voegtlin wrote: I have written a Python-levelDB implementation of this UTXO hashtree, which is currently being tested, and will be added to Electrum

Re: [Bitcoin-development] bitcoin-qt

2013-12-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 JSON-RPC is a huge security risk. It's perfectly reasonable that enabling it requires some technical mumbo-jumbo. Are there specific configuration settings that you would like to see exposed by the GUI? On 12/19/2013 11:49 PM, Chris Evans wrote:

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

2013-12-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Jeremy, Let's give a preview of the application-oriented BIPs I mentioned: Stateless validation and mining involves prefixing transaction and block messages with proofs of their UTxO state changes. These are the operational proofs I describe in

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

2013-12-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Sorry Peter, this was meant for the whole list:) On 12/20/2013 05:17 AM, Peter Todd wrote: I've thought about this for awhile and come to the conclusion that UTXO commitments are a really bad idea. I myself wanted to see them implemented about a

Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees

2013-12-20 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/20/2013 11:48 AM, Gregory Maxwell wrote: A couple very early comments— I shared some of these with you on IRC but I thought I'd post them to make them more likely to not get lost. I got the inputs from IRC, but thank you for posting to the

[Bitcoin-development] BIP proposal: Authenticated prefix trees

2013-12-19 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello fellow bitcoin developers. Included below is the first draft of a BIP for a new Merkle-compressed data structure. The need for this data structure arose out of the misnamed Ultimate blockchain compression project, but it has since been

Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

2013-12-17 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Transactions != blocks. There is no need for a merge block. You are free to trade transactions off-line, so long as you are certain the other parties are not secretly double-spending coins they send you on the block chain. When connection to the

Re: [Bitcoin-development] Merge avoidance and P2P connection encryption

2013-12-13 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/13/2013 09:26 AM, Mike Hearn wrote: I'm thinking about a use case I hope will become common next year - pastebin style hosting sites for payment requests. Like, if I as a regular end user wish to use the payment protocol, I could just upload

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

2013-11-15 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/15/13 4:41 PM, Drak wrote: 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

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

2013-11-15 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/15/13 5:19 PM, Drak wrote: 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

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

2013-11-14 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For this reason I'm in favor of skipping mBTC and moving straight to uBTC. Having eight, or even five decimal places is not intuitive to the average user. Two decimal places is becoming standard for new national currencies, and we wouldn't be too far

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

2013-11-14 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/13 2:00 PM, Alan Reiner 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, it's just something that

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

2013-11-14 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/14/13 3:01 PM, Luke-Jr wrote: 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

Re: [Bitcoin-development] Committing to extra block data/a better merge-mine standard

2013-11-04 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/4/13 10:16 AM, Peter Todd wrote: Again, the right way to do this is define the standard to use the last txout so that midstate compression can be applied in the future. We can re-use this for merge-mining and other commitments easily by

Re: [Bitcoin-development] Committing to extra block data/a better merge-mine standard

2013-11-04 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/4/13 11:38 AM, Mike Hearn wrote: The Merkle branch doesn't get stored indefinitely though, whereas the coinbase hash does. The data stored in the coinbase [output] can always just be the 256-bit root hash truncated to less. I doubt the

Re: [Bitcoin-development] Message Signing based authentication

2013-11-02 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Or SIGHASH of a transaction spending those coins or updating the SIN... On 11/2/13 2:14 PM, 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

Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-30 Thread Mark Friedenbach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 If I understand the code correctly, it's not about rejecting blocks. It's about noticing that 50% of recent blocks are declaring a version number that is meaningless to you. Chances are, there's been a soft fork and you should upgrade. On 10/30/13

  1   2   >