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

2015-06-19 Thread Jorge Timón
On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn m...@plan99.net wrote: Or alternatively, fix the reasons why users would have negative experiences with full blocks It's impossible, Mark. By definition if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were

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

2015-06-18 Thread Jorge Timón
On Tue, Jun 16, 2015 at 2:08 AM, Aaron Voisine vois...@gmail.com wrote: hell even some major changes to the non-consunsus code to make it adequately handle the situation when blocks fill up This will have to eventually be done in addition to any other alternative unless the plan is to keep

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

2015-06-16 Thread Jorge Timón
On Jun 15, 2015 11:43 PM, Rusty Russell ru...@rustcorp.com.au wrote: Though Peter Todd's more general best-effort language might make more sense. It's not like you can hide an OP_RETURN transaction to make it look like something else, so that transaction not going to be distinguished by

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Jorge Timón
On May 31, 2015 5:08 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Sun, May 31, 2015 at 10:59 AM, Jorge Timón jti...@jtimon.cc wrote: Whatever...let's use the current subsidies, the same argument applies, it's just 20 + 25 = 45 btc per block for miner B vs 27 btc for miner B. Miner B

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Jorge Timón
:46 AM, Jorge Timón jti...@jtimon.cc wrote: Here's a thought experiment: Subsidy is gone, all the block reward comes from fees. I wrote about long-term hypotheticals and why I think it is a big mistake to waste time worrying about them here: http://gavinandresen.ninja/when-the-block-reward

Re: [Bitcoin-development] Version bits proposal

2015-05-27 Thread Jorge Timón
On May 27, 2015 11:35 AM, Tier Nolan tier.no...@gmail.com wrote: Was the intention to change the 95% rule. You need 750 of the last 1000 to activate and then must wait at least 1000 for implication? You need 75% to start applying it, 95% to start rejecting blocks that don't apply it.

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

2015-05-27 Thread Jorge Timón
On May 27, 2015 12:58 PM, Peter Todd p...@petertodd.org wrote: What I'm not seeing is how the relative nLockTime that nSequence provides fundamentally changes any of this. This allows the implementation of a rcltv that doesn't make script depend on the current height, in a similar way that

Re: [Bitcoin-development] Version bits proposal

2015-05-26 Thread Jorge Timón
It would also help to see the actual code changes required, which I'm sure will be much shorter than the explanation itself. On May 27, 2015 5:47 AM, Luke Dashjr l...@dashjr.org wrote: On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote: Feel free to comment. As the gist does not support

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

2015-05-13 Thread Jorge Timón
On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen gavinandre...@gmail.com wrote: I think long-term the chain will not be secured purely by proof-of-work. I think when the Bitcoin network was tiny running solely on people's home computers proof-of-work was the right way to secure the chain, and

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

2015-05-13 Thread Jorge Timón
On Wed, May 13, 2015 at 12:31 PM, Alex Mizrahi alex.mizr...@gmail.com wrote: But this matters if a new node has access to the globally strongest chain. If attacker is able to block connections to legitimate nodes, a new node will happily accept attacker's chain. If you get isolated from the

Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

2015-05-12 Thread Jorge Timón
This saves us ocodes for later but it's uglier and produces slightly bigger scripts. If we're convinced it's worth it, seems like the right way to do it, and certainly cltv and rclv/op_maturity are related. But let's not forget that we can always use this same trick with the last opcode to get

Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

2015-05-12 Thread Jorge Timón
I like the reuse with negative numbers more than the current proposal because it doesn't imply bigger scripts. If all problems that may arise can be solved, that is. If we went that route, we would start with the initial CLTV too. But I don't see many strong arguments in favor of using the current

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen gavinandre...@gmail.com wrote: Fee dynamics seems to come up over and over again in these discussions, with lots of talk and theorizing. I hope some data on what is happening with fees right now might help, so I wrote another blog post (with

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 1:29 PM, Mike Hearn m...@plan99.net wrote: I was referring to winter next year. 0.12 isn't scheduled until the end of the year, according to Wladimir. I explained where this figure comes from in this article:

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson d...@hashingit.com wrote: Known: There has been a steady trend towards the mean block size getting larger. See https://blockchain.info/charts/avg-block-size?timespan=allshowDataPoints=falsedaysAverageString=7show_header=truescale=0address= Looking at

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen gavinandre...@gmail.com wrote: I would very much like to find some concrete course of action that we can come to consensus on. Some compromise so we can tell entrepreneurs THIS is how much transaction volume the main Bitcoin blockchain will be able

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 4:05 PM, Mike Hearn m...@plan99.net wrote: If his explanation was I will change my mind after we increase block size, I guess the community should say then we will just ignore your nack because it makes no sense. Oh good! We can just kick anyone out of the consensus

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Jorge Timón
On Thu, May 7, 2015 at 6:11 PM, Mike Hearn m...@plan99.net wrote: It is an argument against my admittedly vague definition of non-controversial change. If it's an argument against something you said, it's not a straw man, right ;) Yes, but it was an argument against something I didn't said

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-05-05 Thread Jorge Timón
orthogonal to the nSequence-based RCLTV proposal itself. On Tue, May 5, 2015 at 2:41 AM, Btc Drak btcd...@gmail.com wrote: On Mon, May 4, 2015 at 12:24 PM, Jorge Timón jti...@jtimon.cc wrote: What I was describing was an attempt to fix a similar proposal by Mark Friedenbach, but it didn't needed

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-05-04 Thread Jorge Timón
What I was describing was an attempt to fix a similar proposal by Mark Friedenbach, but it didn't needed fixing: I was simply misunderstanding it. Mark's RCLTV is completely reorg safe, so there's no need for the 100 block restriction. It also keeps the script validation independent from the utxo.

Re: [Bitcoin-development] Where do I start?

2015-04-30 Thread Jorge Timón
As Mike says it depends on your interests. But one thing that is almost always welcomed is improving the tests, and it is unlikely that it conflicts with other people's PRs (unless they're changing that part of the code and need to update those tests. Improving documentation is also good and you

Re: [Bitcoin-development] Where do I start?

2015-04-30 Thread Jorge Timón
to understand Bitcoin protocol and make progress in java to become a good developper. Please tell me how I can begin. Best regards 2015-04-30 10:08 GMT+02:00 Jorge Timón jti...@jtimon.cc: As Mike says it depends on your interests. But one thing that is almost always welcomed is improving the tests

Re: [Bitcoin-development] Proof of Payment

2015-04-28 Thread Jorge Timón
Forget it, sorry, I misunderstood the proposal entirely, re-reading with more care... On Tue, Apr 28, 2015 at 2:41 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Hi Jorge, I don't think I understand the question. Proof of Payment is used to prove that you have the credentials needed for a

Re: [Bitcoin-development] Proof of Payment

2015-04-28 Thread Jorge Timón
So at the low level, how does a proof of payment differ from just proving that a given transaction is in a given block (what SPV nodes take as proof of payment today)? On Apr 27, 2015 2:42 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: Or a really high lock_time, but it would not make it invalid,

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-04-28 Thread Jorge Timón
of for op_maturity too, but that's the wingle decision about rcltv/maturity that affects cltv so better solve that first. On Apr 27, 2015 9:35 PM, Peter Todd p...@petertodd.org wrote: On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote: On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-04-26 Thread Jorge Timón
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote: There's another possibility that could keep the utxo out of Script verification: class CTxIn { public: COutPoint prevout; CScript scriptSig; uint32_t nSequence; } could turn into: class CTxIn { public

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-04-26 Thread Jorge Timón
On Tue, Apr 21, 2015 at 9:59 AM, Peter Todd p...@petertodd.org wrote: Thus we have a few possibilities: 1) RCLTV against nLockTime Needs a minimum age COINBASE_MATURITY to be safe. 2) RCLTV against current block height/time Completely reorg safe. Yes, can we call this one OP_MATURITY

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

2015-04-24 Thread Jorge Timón
s7r you may be interested in this video explaining several aspects of malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs It is pre BIP62, but I believe it is very relevant and will hopefully clear some of your doubts. The signer of TX1 will always be able to change the signature and thus

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

2015-04-24 Thread Jorge Timón
Oh, no, sorry, it also covers bip62. On Fri, Apr 24, 2015 at 10:55 AM, Jorge Timón jti...@jtimon.cc wrote: s7r you may be interested in this video explaining several aspects of malleability: https://www.youtube.com/watch?v=jyDE-aFqJTs It is pre BIP62, but I believe it is very relevant

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

2015-03-24 Thread Jorge Timón
That case is very unlikely IMO, but still you can solve it while keeping hash of the genesis block as the chain id. If a community decides to accept a forking chain with new rules from block N (let's call it bitcoinB), the original chain can maintain the original genesis block and the new

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

2015-02-21 Thread Jorge Timón
On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@bitpay.com wrote: scorched earth refers to the _real world_ impact such policies would have on present-day 0-conf usage within the bitcoin community. When I posted this: http://sourceforge.net/p/bitcoin/mailman/message/32263765/ Peter Todd

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

2015-02-21 Thread Jorge Timón
I agree scorched hearth is a really bad name for the 0 conf protocol based on game theory. I would have preferred stag hunt since that's basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt) but I like the protocol and I think it would be interesting to integrate it in the

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

2015-02-19 Thread Jorge Timón
On Thu, Feb 19, 2015 at 6:30 PM, Mike Hearn m...@plan99.net wrote: He didn't said a project for all possible language bindings, just java bindings. Other languages' bindings would be separate projects. Yes/no/sorta. Java/JNA bindings can be used from Python, Ruby, Javascript, PHP as well as

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

2015-02-19 Thread Jorge Timón
On Thu, Feb 19, 2015 at 3:09 PM, Tamas Blummer ta...@bitsofproof.com wrote: On Feb 19, 2015, at 3:03 PM, Bryan Bishop kanz...@gmail.com wrote: Second, I think that squeezing all possible language bindings into a project is also unproductive. The language binding would be an independent and

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

2015-02-14 Thread Jorge Timón
On Sat, Feb 14, 2015 at 3:23 PM, Tamas Blummer ta...@bitsofproof.com wrote: Peter, We have seen that the consensus critical code practically extends to Berkley DB limits or OpenSSL laxness, therefore it is inconceivable that a consensus library is not the same as Bitcoin Core, less its P2P

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-30 Thread Jorge Timón
On Mon, Dec 29, 2014 at 10:34 PM, Justus Ranvier justus.ranv...@monetas.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/29/2014 09:10 PM, Mike Hearn wrote: How does adding inputs to a coinbase differ from just having pay-to-fee transactions in the block? If a miner

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

2014-12-21 Thread Jorge Timón
st On Sun, Dec 21, 2014 at 6:52 AM, Peter Todd p...@petertodd.org wrote: On Sun, Dec 21, 2014 at 11:57:51AM +0800, Mark Friedenbach wrote: I think you are trying to say something more specific / limited than that, and I suggest you adjust your wording accordingly. Decentralized exchange would

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

2014-12-21 Thread Jorge Timón
On Sun, Dec 21, 2014 at 5:07 PM, Peter Todd p...@petertodd.org wrote: On Sun, Dec 21, 2014 at 12:25:36PM +0100, Jorge Timón wrote: So let's go through an example to see in which ways non-proof-of-publication orders are insecure. Alice the seller wants to sell 1 unit of A for 100 units of B

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

2014-11-17 Thread Jorge Timón
On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon flavien.char...@coinprism.com wrote: Storing only a hash is fine for the most basic timestamping application, but it's hardly enough to build something interesting. No, storing only a hash is enough for ALL timestamping applications. If you

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

2014-11-16 Thread Jorge Timón
I agree with Luke, we can endlessly discuss the best defaults like the default size allowed for OP_RETURN, minimum fees, anti-dust policies, first-seen vs replace-by-fee, etc; but the fact is that policies depend on miners. Unfortunately most miners and pools are quite apathetic when it comes to

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

2014-11-16 Thread Jorge Timón
://github.com/Blockstream/contracthashtool On Sun, Nov 16, 2014 at 7:44 PM, Jorge Timón jti...@jtimon.cc wrote: I agree with Luke, we can endlessly discuss the best defaults like the default size allowed for OP_RETURN, minimum fees, anti-dust policies, first-seen vs replace-by-fee, etc; but the fact

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

2014-11-03 Thread Jorge Timón
On Mon, Nov 3, 2014 at 1:12 PM, Alex Mizrahi alex.mizr...@gmail.com 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).

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

2014-11-03 Thread Jorge Timón
On Mon, Nov 3, 2014 at 5:01 PM, Alex Mizrahi alex.mizr...@gmail.com wrote: This isn't applicable in case of sidechains: anybody with sufficient hashpower will be able to unlock a locked coin on the parent chain by producing an SPV proof. Only if the miners form a shared valid history isn't a

Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)

2014-10-05 Thread Jorge Timón
On Mon, Oct 6, 2014 at 1:40 AM, Gregory Maxwell gmaxw...@gmail.com wrote: Something you might want to try to formalize in your analysis is the proportion of the network which is rational vs honest/altruistic. Intuitively, if there is a significant amount of honest hashrate which is refusing

Re: [Bitcoin-development] How to create a pull tester JAR

2014-08-06 Thread Jorge Timón
to the framework coordinate with him first to ensure you don't end up conflicting with a big refactor/rewrite. -- Jorge Timón -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications

Re: [Bitcoin-development] Bitcoin Protocol Specification

2014-07-08 Thread Jorge Timón
___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón -- Open source

Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-25 Thread Jorge Timón
the extensions process more formally. IMO we need a living document version of the payment protocol with all the different extensions out there folded into it, to simplify programming tasks and ensure field numbers don't collide. -- Jorge Timón

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Jorge Timón
On 6/24/14, Mike Hearn m...@plan99.net wrote: bitcoind already supports SPV mode, that's how bitcoinj clients work. However the current wallet code doesn't use it, it integrates directly with the full mode main loop and doesn't talk P2P internally. Which is the fine and obvious way to

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Jorge Timón
On 6/24/14, Tamas Blummer ta...@bitsofproof.com wrote: 3. Services e.g. exchange, payment processor This is where core + indexing server talking SPV to core is the right choice I think this is my main question, what's the advantage of having the processes talking via the p2p protocol

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Jorge Timón
On 6/24/14, Justus Ranvier justusranv...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/24/2014 09:07 AM, Wladimir wrote: My main argument for the split is that full nodes and wallets have completely different usage scenarios: - A wallet should be online as little as

[Bitcoin-development] Plans to separate wallet from core

2014-06-23 Thread Jorge Timón
in this thread. -- Jorge Timón -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-16 Thread Jorge Timón
On 6/16/14, Mike Hearn m...@plan99.net wrote: If they decide to change to something like highest-fee-always-wins, then they (again) centralise things by forcing all instant transactions to pay GreenAddress and its competitors money - much though I like your product Lawrence, let's hope they

Re: [Bitcoin-development] BIP - Hash Locked Transaction

2014-04-26 Thread Jorge Timón
Does it make sense to implement a generic Policy interface (abstract class) which StandardPolicy extends? Maybe you can then implement a WhitelistPolicy, ReplacebyFeeStandardPolicy, ReplacebyFeeWhitelistPolicy... This would make it simpler for miners to implement their own policies in general.

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Jorge Timón
is secure and I fear that at best you will end up with an invite only transaction processing network like Ripple.com has with their consensus algorithm and Unique Node Lists: that's not really p2p. -- Jorge Timón http://freico.in

[Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Jorge Timón
it is the more rational way for them to prioritize transactions. Finally I hope they do because it would make 0-confirmation transactions possible as described in this post. So I can't find any reasoning against replace-by-fee unless my example is terribly flawed. Am I missing something? -- Jorge Timón http

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Jorge Timón
On 4/24/14, Mike Hearn m...@plan99.net wrote: No! This is a misunderstanding. The mechanism they use to prevent double spends is to *ignore double spends*. The blocks they created indicate the ordering of transactions they saw and proof of work is used to arrive at a shared consensus ordering

Re: [Bitcoin-development] 0 confirmation txs using replace-by-fee and game theory

2014-04-24 Thread Jorge Timón
On 4/24/14, Peter Todd p...@petertodd.org wrote: ... With replace-by-fee scorched-earth the success rate of such double-spends would be significantly reduced as the attacker would need to get lucky with bad propagation not just once, but twice in a row. Interesting. Replace-by-fee and

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Jorge Timón
On 4/24/14, Mike Hearn m...@plan99.net wrote: You can't disentangle the two. Proof of work just makes a block chain hard to tamper with. What it contains is arbitrary. Honest miners build a block chain that's intended to stop double spending. Dishonest miners don't. They're both engaging in

Re: [Bitcoin-development] Economics of information propagation

2014-04-21 Thread Jorge Timón
are just as good for providing 1 of the 6 confirms needed too. -- Jorge Timón http://freico.in/ -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java

[Bitcoin-development] Timed testing

2014-04-17 Thread Jorge Timón
comments on the parameters, defaults or any other design or implementation details are also welcomed. -- Jorge Timón http://freico.in/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive

Re: [Bitcoin-development] Timed testing

2014-04-17 Thread Jorge Timón
On 4/17/14, Mike Hearn m...@plan99.net wrote: 2) If I wanted to measure validation performance, to get the number of peak tps that could be processed without taking block sides or network latency into account, how would I do that? Has anybody tried this before? You can just reindex/replay

Re: [Bitcoin-development] Timed testing

2014-04-17 Thread Jorge Timón
was going to review all that part of the code to externally write the private mode anyway. -- Jorge Timón http://freico.in/ -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new

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

2014-04-07 Thread Jorge Timón
On 4/7/14, Flavien Charlon flavien.char...@coinprism.com wrote: Also those 54 BTC (actually 5.4 BTC if the dust is now 540 satoshis) become part of the capital of the company, and can always be recovered by uncoloring the shares. It's an investment, not an expense, so I think it is acceptable.

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

2014-04-07 Thread Jorge Timón
On 4/7/14, Flavien Charlon flavien.char...@coinprism.com wrote: Ok, I guess I'm not using the proper terminology. It would be listed on the Asset section of the company's balance sheet, is what I meant. No, it's an asset for the owner of the share, not the company, just like the gold plates are

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-05 Thread Jorge Timón
/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón http

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-05 Thread Jorge Timón
On 4/5/14, Matt Whitlock b...@mattwhitlock.name wrote: On Saturday, 5 April 2014, at 12:21 pm, Jorge Timón wrote: I like both DD-MM- and -MM-DD. I just dislike MM-DD- and -DD-MM. Your preferences reflect a cultural bias. The only entirely numeric date format

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Jorge Timón
/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in/ -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https

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

2014-03-27 Thread Jorge Timón
I'll make sure I understand your proposal better before commenting much on it, but at a first glance, I don't see how it is incompatible with 2 way peg and merged mining itself. Why wouldn't you want merged mining for the root of your tree? A miner could only chose a leaf block at a time, but it

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

2014-03-22 Thread Jorge Timón
for free, please, enlighten us, how that's done? It should be easier with the scamcoin ixcoin, with a much lower subsidy to miners so I don't feel bad about the suggestion if your free attack somehow works (certainly using some magic I don't know about). -- Jorge Timón http://freico.in

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

2014-03-16 Thread Jorge Timón
those transactions or maybe updating its committed utxo when it has proofs that the coins have been withdrawn. [1] http://freico.in/docs/freimarkets.pdf https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers -- Jorge Timón http://freico.in

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

2014-03-13 Thread Jorge Timón
On 3/13/14, Troy Benjegerdes ho...@hozed.org wrote: cynic hat: on Every volatility bump messes up expectations of what a bitcoin is worth, so why are we bikeshedding uBTC vs mBTC? Just be done with it and do mBTC now, and plan uBTC for just after the next price spike to $10KUSD or whatever,

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

2014-03-13 Thread Jorge Timón
On 3/13/14, Mike Hearn m...@plan99.net wrote: You would only need to change it if there was a sub-satoshi hardfork, which doesn't seem necessary anytime soon. + We shouldn't make any assumptions about the future price of bitcoin to make the decision. Hmmm ;) Didn't you just make an

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

2014-03-02 Thread Jorge Timón
___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in

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

2014-02-28 Thread Jorge Timón
in summary, I feel like before actually solving the problem we need to rise more awareness on how nice and necessary nExpiryTime would be. Anyway, sorry, I just wanted to point out another use, a deeper discussion about this belongs to another thread. -- Jorge Timón http://freico.in

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

2014-02-27 Thread Jorge Timón
not to always have to double-spend the inputs of an order to cancel it. -- Jorge Timón http://freico.in/ -- Flow-based real-time traffic analytics software. Cisco certified tool. Monitor traffic, SLAs, QoS, Medianet

Re: [Bitcoin-development] Embedded consensus system upgrade procedures

2014-02-15 Thread Jorge Timón
___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in/ -- Android apps run on BlackBerry 10

Re: [Bitcoin-development] Combining big transactions with hash-only blocks to improve tps.

2014-01-22 Thread Jorge Timón
___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-10 Thread Jorge Timón
On 1/10/14, Peter Todd p...@petertodd.org wrote: Fair enough. Do you see any case where an independently pow validated altcoin is more secure than a merged mined one? Situations where decentralized consensus systems are competing for market share in some domain certainely apply. For instance

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-10 Thread Jorge Timón
On 1/10/14, Peter Todd p...@petertodd.org wrote: Come to think of it, we've got that exact situation right now: the new Twister P2P Microblogging thing has a blockchain for registering usernames that could have been easily done with Namecoin, thus in theory Namecoin owners have an incentive to

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-09 Thread Jorge Timón
On 1/6/14, Peter Todd p...@petertodd.org wrote: On Sat, Jan 04, 2014 at 01:27:42AM +0100, Jorge Timón wrote: It's not meant to prove anything - the proof-of-sacrificed-bitcoins mentioned(*) in it is secure only if Bitcoin itself is secure and functional. I referred you to it because

Re: [Bitcoin-development] Merge mining

2014-01-04 Thread Jorge Timón
On 1/4/14, David Vorick david.vor...@gmail.com wrote: If you have the resources to attack one of the bigger altcoins, you probably have a significant investment in the cryptocurrency space, and a significant interest in protecting it. Compromising even something like dogecoin would cause a lot

Re: [Bitcoin-development] Merge mining

2014-01-04 Thread Jorge Timón
has anything to do with MM. On Sat, Jan 4, 2014 at 5:05 AM, Jorge Timón jti...@monetize.io wrote: On 1/4/14, David Vorick david.vor...@gmail.com wrote: If you have the resources to attack one of the bigger altcoins, you probably have a significant investment in the cryptocurrency space

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

2014-01-03 Thread Jorge Timón
On 1/3/14, Troy Benjegerdes ho...@hozed.org wrote: 'make' should check the hash. An attacker could replace that part of the makefile. Anyway, I think this is more oriented for compiled binaries, not for people downloading the sources. I assume most of that people just use git. The binary

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-03 Thread Jorge Timón
On 1/1/14, Peter Todd p...@petertodd.org wrote: On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote: On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote: that you are using merge-mining is a red-flag because without majority, or at least near-majority, hashing power an attacker

Re: [Bitcoin-development] The insecurity of merge-mining

2014-01-03 Thread Jorge Timón
On 1/3/14, Peter Todd p...@petertodd.org wrote: On Fri, Jan 03, 2014 at 08:14:25PM +0100, Jorge Timón wrote: You assume the value of a crypto-currency is equal to all miners, it's not. They should be able to sell the reward at similar prices in the market. Attackers are losing

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

2014-01-02 Thread Jorge Timón
On 12/31/13, Mike Hearn m...@plan99.net wrote: remember suggesting that we whack Google Analytics or some other statistics package on when the new website design was done and that was rejected for similar reasons (organisations are bad). Analytics software would be useful. I suggest using

Re: [Bitcoin-development] Monetary Authority for Bitcoin

2013-12-10 Thread Jorge Timón
, specially if (as you've shown to us) you are not interested in learning why this proposal is unfeasible. -- Jorge Timón http://freico.in/ -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single

Re: [Bitcoin-development] Popularity based mining (variable block reward)

2013-12-10 Thread Jorge Timón
/gampad/clk?id=84349831iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in

Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys

2013-10-24 Thread Jorge Timón
/lists/listinfo/bitcoin-development -- Jorge Timón http://freico.in/ -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced

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

2013-10-21 Thread Jorge Timón
and modified. -- Jorge Timón http://freico.in/ -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get

Re: [Bitcoin-development] Faster databases than LevelDB

2013-09-17 Thread Jorge Timón
On 9/17/13, Mike Hearn m...@plan99.net wrote: Nobody has written code to use a better format, migrate old wallets, etc. ACK, thanks. -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours

Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind

2013-08-19 Thread Jorge Timón
listreceivedbyaddress listtransactions sendmany I think this would also leave a cleaner API, but I'm just interested on what the objections would be to this removal. How crazy does this sound? Should we reconsider their removal for freicoin, proceed or create a pull request for bitcoin? -- Jorge Timón

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

2013-07-15 Thread Jorge Timón
desirable from a privacy standpoint. Basically it reduces the privacy risks of doing the exchange to spending the Zerocoins in the first place. -- 'peter'[:-1]@petertodd.org 00878c30a45104c48fd4e8037cb5b3ba1e14dc4d8bef72eff1be -- Jorge Timón http://freico.in

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

2013-07-14 Thread Jorge Timón
. On 7/13/13, Adam Back a...@cypherspace.org wrote: 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

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

2013-07-13 Thread Jorge Timón
no reason to think the zerocoin chain transaction rate needs to be especially high anyway. -- 'peter'[:-1]@petertodd.org 0013b2f7ee77027f583b765ad9811dfe3d0adc801e295fd9acdf -- Jorge Timón http://freico.in

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

2013-07-13 Thread Jorge Timón
Sorry about that. Maybe more important, what's wrong with bitcoin and zerocoin being different currencies with an exchange rate completely decided by the market instead of trying to force 1:1 ??? On 7/13/13, Jorge Timón jti...@monetize.io wrote: I'm not sure I understand the whole proposal

Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-10 Thread Jorge Timón
proof stuff anyway. I thought about this before, I like the idea very much. Would such a fork be controversial for anyone? Would anyone oppose to this for some reason I'm missing? -- Jorge Timón http://freico.in/ -- Precog

Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-13 Thread Jorge Timón
@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Stephen Pair, Co-Founder, CTO Does *your* website accept cash? bitpay.com [image: bitpay-small] ABC6 C11B BF75 9E2B FC6A B3E0 7B96 40B2 CAC0 C158 -- Jorge Timón http://freico.in/ http://archive.ripple

Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-11 Thread Jorge Timón
happen, just give up on that idea. The negative publicity of the bitcoin developers are destroying YOUR coins! would be devastating. -- -- Gavin Andresen -- Jorge Timón http://freico.in/ http://archive.ripple-project.org

Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-11 Thread Jorge Timón
miner. On Mar 11, 2013, at 7:01 AM, Jorge Timón jtimo...@gmail.com wrote: On 3/10/13, Peter Todd p...@petertodd.org wrote: It's also been suggested multiple times to make transaction outputs with a value less than the transaction fee non-standard, either with a fixed constant or by some sort

  1   2   >