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 using it will be
 kicked out to make way for the others. Whether that happens in some kind of
 stable organised way or (as with the current code) a fairly chaotic way
 doesn't change the fundamental truth: some users will find their bitcoin
 savings have become uneconomic to spend.

He doesn't mean that: he means solving the mempool and crashes and
hitting the limit would have.
If the chain has limited size it is a scarce resource and people have
to bid for it: nothing unexpected or wrong about that.
Of course, people that believe the limit should be completely removed
eventually because they don't care about mining being decentralized
(or fail to see the relation between the two) may have a very
different view about this.

On Fri, Jun 19, 2015 at 12:08 PM, GC slashdevn...@hotmail.com wrote:
 Timeframe for transaction fees topping block reward fees = many years in
 the future, based on current ratio of block reward to fees.

Do you think that this ratio is unrelated to an abundant (non-scarce)
block size?
When is the right time to allow space pressure to rise that ratio?
When the subsidy is at 1.5625, for example, it may be too late to
start a non-catastrophic transition from subsidies to fees.
I don't claim to know that, but it's something that worries me.
No matter how many people say that's too far away in the future to
worry about it, I still worry about it and I'm sure more people do.
What if when it's time to care about it we discover that we should
have started to do things about it long ago to minimize the risks of
this transition?

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 non-canonical ordering.

What about commitments that don't use op_return (ie pay2contract
commitments)?

In any case, if the motivation is ordering in multi-party transactions
there should be ways to do it without any consequences for other
transaction types' privacy. For example you could have a deterministic
method that depends on a random seed all parties in the transaction
previously share. That way the ordering is deterministic for all parties
involved in the transaction (which can use whatever channel they're using
to send the parts to also send this random seed) while at the same time the
order looks random (or at least not cannonical in a recognisable way) to
everyone else.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 would still go out of business, bigger blocks still mean more
mining and validation centralization

 Sorry, but that's ridiculous.

 If Miner B is leaving 18BTC per block on the table because they have bad
connectivity, then they need to pay for better connectivity.

Well, I was assuming they just can't upgrade their connection (without
moving thei operations to another place). Maybe that assumption is
ridiculous as well.

 If you are arguing I should be able to mine on a 56K modem connection
from the middle of the Sahara then we're going to have to agree to
disagree.

No, I'm not suggesting that.

 So: what is your specific proposal for minimum requirements for
connectivity to run a full node? The 20MB number comes from estimating
costs to run a full node, and as my back-and-forth to Chang Wung shows, the
costs are not excessive.

Well, you were I think assuming a new desktop connecting from somewhere in
the US. I would be more confortable with an eee pc from a hotel in India,
for example. But yeah, targeting some concrete minimum specs seems like the
right approach for deciding how far to go when increasing centralization.

But hitting the limit will be chaos seems to imply that completely
removing the consensus maximum blocksize is the only logical solution. What
happens when we hit the limit next time? When do we stop kicking the can
down the road? When do we voluntarily get that chaos?
Again, that's too far away in the future to worry about it is not a very
conving answer to me.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-31 Thread Jorge Timón
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 would still go out of business, bigger blocks still mean more
mining and validation centralization. The question is how far I we willing
to go with this scaling by sacrificing decentralization, but the answer
can't be that's to far away in the future to worry about it, right now as
far as we think we can using orphan rate as the only criterion.
On May 31, 2015 4:49 PM, Gavin Andresen gavinandre...@gmail.com wrote:

 On Sun, May 31, 2015 at 10: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-goes-away


 --
 --
 Gavin Andresen

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 cltv uses the nLockTime (which
has been compared with the current height already when checking the script).
In fact, the implementation could be simpler if the goal of maintaining the
original nSequence semantics was ignored ( although not that simpler, but
you wouldn't need to use ~ (bitwise not).
I'm still not sure whether there should be 2 BIPs for this or just one.

 --
 'peter'[:-1]@petertodd.org
 01643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6


--

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 notifying participants
  of new comments, I would suggest using the mailing list instead.

 I suggest adding a section describing how this interacts with and changes
 GBT.

 Currently, the client tells the server what the highest block version it
 supports is, and the server indicates a block version to use in its
 template,
 as well as optional instructions for the client to forcefully use this
 version
 despite its own maximum version number. Making the version a bitfield
 contradicts the increment-only assumption of this design, and since GBT
 clients are not aware of overall network consensus state, reused bits can
 easily become confused. I suggest, therefore, that GBT clients should
 indicate
 (instead of a maximum supported version number) a list of softforks by
 identifier keyword, and the GBT server respond with a template indicating:
 - An object of softfork keywords to bit values, that the server will
 accept.
 - The version number, as presently conveyed, indicating the preferred
 softfork
 flags.

 Does this sound reasonable, and/or am I missing anything else?

 Luke


 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 the only
 fair way to both secure the chain and distribute the coins.

 See https://gist.github.com/gavinandresen/630d4a6c24ac6144482a  for some
 half-baked thoughts along those lines. I don't think proof-of-work is the
 last word in distributed consensus (I also don't think any alternatives are
 anywhere near ready to deploy, but they might be in ten years).

Or never, nobody knows at this point.

 I also think it is premature to worry about what will happen in twenty or
 thirty years when the block subsidy is insignificant. A lot will happen in
 the next twenty years. I could spin a vision of what will secure the chain
 in twenty years, but I'd put a low probability on that vision actually
 turning out to be correct.

I think is very healthy to worry about that since we know it's
something that will happen.
The system should work without subsidies.

 That is why I keep saying Bitcoin is an experiment. But I also believe that
 the incentives are correct, and there are a lot of very motivated, smart,
 hard-working people who will make it work. When you're talking about trying
 to predict what will happen decades from now, I think that is the best you
 can (honestly) do.

Lightning payment channels may be a new idea, but payment channels are
not, and nobody is using them.
They are the best solution to scalability we have right now,
increasing the block size is simply not a solution, it's just kicking
the can down the road (while reducing the incentives to deploy real
solutions like payment channels).

Not worrying about 10 years in the future but asking people to trust
estimates and speculations about how everything will burn in 2 years
if we don't act right now seems pretty arbitrary to me.
One could just as well argue that there's smart hard-working people
that will solve those problems before they hit us.

It is true that the more distant the future you're trying to predict
is, the more difficult it is to predict it, but any threshold that
separates relevant worries from too far in the future to worry
about it will always be arbitrary.
Fortunately we don't need to all share the same time horizon for what
is worrying and what is not.
What we need is a clear criterion for what is acceptable for a
hardfork and a general plan to deploy them:

-Do all the hardfork changes need to be uncontroversial? How do we
define uncontroversial?
-Should we maintain and test implementation of hardfork whises that
seem too small to justify a hardfork on their own (ie time travel fix,
allowing to sign inputs values...) to also deploy them at the same
time that other more necessary hardforks?

I agree that hardforks shouldn't be impossible and in that sense I'm
glad that you started the hardfork debate, but I believe we should be
focusing on that debate rather than the block size one.
Once we have a clear criteria, hopefully the block size debate should
become less noisy and more productive.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 network you may not get the longest valid
chain. I don't think any other consensus mechanism deals with this
better than Bitcoin.

 So PoW, by itself, doesn't give strong security guarantees. This problem is
 so fundamental people avoid talking about it.

 In practice, Bitcoin already embraces weak subjectivity e.g. in form of
 checkpoints embedded into the source code. So it's hard to take PoW purists
 seriously.

Checkpoints are NOT part of the consensus rules, they're just an
optimization that can be removed.
Try keeping the genesis block as your only checkpoint and rebuild: it
will work. You can also define your own checkpoints, there's no need
for everyone to use the same ones.
In a future with committed utxo the optimization could be bigger, but
still, we shouldn't rely on checkpoints for consensus, they're just an
optimization and you should only trust checkpoints that are buried in
the chain. Trusting a committed utxo checkpoint from 2 years ago
doesn't seem very risky. If the code is not already done (not really
sure if it was done as part of auto-prune), we should be prepared for
reorgs that invalidate checkpoints.
So, no, Bitcoin does NOT rely on that weak subjectivity thing.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

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 2^64 brand new opcodes.
So I'm not convinced at all on whether we want  #5496 or #6124.
But it would be nice to decide and stop blocking  this.

On Sat, May 9, 2015 at 11:12 AM, Peter Todd p...@petertodd.org wrote:
 On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote:
  That said, if people have strong feelings about this, I would be willing
  to make OP_CLTV work as follows:
 
  nLockTime 1 OP_CLTV
 
  Where the 1 selects absolute mode, and all others act as OP_NOP's. A
  future relative CLTV could then be a future soft-fork implemented as
  follows:
 
  relative nLockTime 2 OP_CLTV
 
  On the bad side it'd be two or three days of work to rewrite all the
  existing tests and example code and update the BIP, and (slightly) gets
  us away from the well-tested existing implementation. It also may
  complicate the codebase compared to sticking with just doing a Script
  v2.0, with the additional execution environment data required for v2.0
  scripts cleanly separated out. But all in all, the above isn't too big
  of a deal.


 Adding a parameter to OP_CLTV makes it much more flexible and is the most
 economic use of precious NOPs.
 The extra time required is ok and it would be good to make this change to
 the PR in time for the feature freeze.

 Done!

 https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263

 --
 'peter'[:-1]@petertodd.org
 12c438a597ad15df697888be579f4f818a30517cd60fbdc8

 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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
trick later when we're actually running out of opcodes, just that
CLTV and RCLTV/op_maturity are semantically related. How
semantically related depends on the final form of RCLTV/op_maturity,
but I don't think anybody wants to block CLTV until RCLTV is ready.

So we could just deploy the initial CLTV (#6124) now and then decide
whether we want to reuse it with negatives for RCLTV or if we use an
independent op.
Can the people that don't like that plan give stronger arguments in
favor of the parametrized version?

I've missed IRC conversations, so I may be missing something...


On Tue, May 12, 2015 at 11:01 PM, Peter Todd p...@petertodd.org wrote:
 On Tue, May 12, 2015 at 08:38:27PM +, Luke Dashjr wrote:
 It should actually be straightforward to softfork RCLTV in as a negative 
 CLTV.
 All nLockTime are = any negative number, so a negative number makes CLTV a
 no-op always. Therefore, it is clean to define negative numbers as relative
 later. It's also somewhat obvious to developers, since negative numbers often
 imply an offset (eg, negative list indices in Python).

 Doing this makes handling the year 2038 problem a good deal more
 complex.

 The CLTV codebase specifically fails on negative arguments to avoid any
 ambiguity or implementation differences here.

 --
 'peter'[:-1]@petertodd.org
 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7

 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 graphs, which can't be done in a mailing list
 post):
http://gavinandresen.ninja/the-myth-of-not-full-blocks

 We don’t need 100% full one megabyte blocks to start to learn about what is
 likely to happen as transaction volume rises and/or the one megabyte block
 size limit is raised.

Ok, the fact that the fee increases the probability of getting
included faster already is a good thing, the graphs with the
probability of getting included in the next block were less important
to me.
Although scarce space (beyond what miners chose to limit by
themselves) would increase the fee competition, I didn't knew that
there is actually some competition happening already.
So I guess this diminishes the argument for maintaining the limits
longer to observe the results of more scarce space.
Still, I think maintaining a lower policy limit it's a good idea, even
if we decide not to use it to observe that soon.
For example, say we chose the 20 MB consensus limit, we can maintain
the policy limit at 1 MB or move it to 2 MB, and slowly moving it up
later as needed without requiring everyone to upgrade.
Of course, not all miners have to follow the standard policy, but at
least it's something.
So please take this as a suggestion to improve your proposal. You can
argue it like this if we want to maintain the limits after the
hardfork or increase them slowly, for observing fee dynamics with more
scarce space or for any other reason, those limits can be partially
enforced by the standard policy. I mean, I think that could be a
reasonable compromise for that concrete line of arguments.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase

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:

 https://medium.com/@octskyward/bitcoin-s-seasonal-affective-disorder-35733bab760d

 It's a fairly simple estimate based on previous growth patterns.

Ok, thanks.

 We've successfully reached consensus for several softfork proposals
 already.


 Are you sure about that?

Yes, Peter Todd gave more details.

 What if Gavin popped up right now and said he disagreed with every current
 proposal, he disagreed with side chains too, and there would be no consensus
 on any of them until the block size limit was raised.

 Would you say, oh, OK, guess that's it then. There's no consensus so might
 as well scrap all those proposals, as they'll never happen anyway. Bye bye
 side chains whitepaper.

Well, yes, it is true that universally uncontroversial (which is
what I think the requirement should be for hard forks) is a vague
qualifier that's not formally defined anywhere.
I guess we should only consider rational arguments. You cannot just
nack something without further explanation.
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.
In the same way, when people use fallacies (purposely or not) we must
expose that and say this fallacy doesn't count as an argument.
But yeah, it would probably be good to define better what constitutes
a sensible objection or something. That doesn't seem simple though.

 I just hope that by  What we need to see right now is leadership you
 don't mean something like when Gaving and Mike agree it's enough to
 deploy a hardfork when you go from vague to concrete.


 No. What I meant is that someone (theoretically Wladimir) needs to make a
 clear decision. If that decision is Bitcoin Core will wait and watch the
 fireworks when blocks get full, that would be showing leadership .
 albeit I believe in the wrong direction. It would, however, let people know
 what's what and let them start to make longer term plans.

 This dillydallying around is an issue - people just make vague points that
 can't really be disagreed with (more nodes would be nice, smaller pools
 would also be nice etc), and nothing gets done.

Well, there's two different things here.
One thing is the Bitcoin core project where you could argue that the 5
committers decide (I don't know why Wladimir would have any more
authority than the others).
But what the bitcoin network itself does it's very different because
unlike the bitcoin core software project, the Bitcoin network is
decentralized.
If the people with commit access go nuts and decide something that's
clearly stupid or evil, people can just fork the project because it is
free software.
You cannot be forced to use specific features of free software, you
can always remove them and recompile, that's the whole point.
So, no, there's no authority to decide on hardforks and that's why I
think that only clearly uncontroversial things can get through as
hardforks.

 What you want to avoid at all cost (the block size actually being
 used), I see as the best opportunity we have to look into the future.


 I think I see one of the causes of disagreement now.

 I will write more on the topic of what will happen if we hit the block size
 limit soon, maybe this evening. I have some other tasks to do first.

 Regardless, I don't believe we will get any useful data out of such an
 event. I've seen distributed systems run out of capacity before. What will
 happen instead is technological failure followed by rapid user abandonment
 that pushes traffic back below the pressure threshold  and those users
 will most likely not come back any time soon.

Ok, so in simple terms, you expect people to have to pay enormous fees
and/or wait thousands of blocks for their transactions to get included
in the chain.
Is that correct?

 Ok, this is my plan: we wait 12 months, hope that your estimations are
 correct (in case that my guess was better than yours, we keep waiting
 until June 2017) and start having full blocks and people having to
 wait 2 blocks for their transactions to be confirmed some times.


 I disagree that'd be the outcome, but good, this is progress. Now we need to
 hear something like that from Wladimir, or whoever has the final say around
 here.

As said above there's no authority to decide on what Bitcoin the p2p
network does. Again, that's the whole point.
But, yes, I agree that both sides understanding each other better is progress.

 With respect to the fee market: I think it's fairer to say Gavin wants a
 market to exist, and he also wants supply to be plentiful. 20mb limit
 doesn't actually mean every block will be 20mb the day after, no more than
 they're all 1mb today. Miners may discover that if they go beyond 5mb 

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 this graph and in retrospective, we shouldn't have removed
the standard policy limit without observing the supposedly disastrous
effects of hitting the limit first.
Removing the standard limit would have been trivial (bdb issues aside)
at any point after seeing the effects.

 Known: If we reach the point where all blocks are 1M bytes then there's a
 major problem in terms of transaction confirmation. I published an analysis
 of the impact of different mean block sizes against confirmation times:
 http://hashingit.com/analysis/34-bitcoin-traffic-bulletin. The current 35%
 to 45% mean block size doesn't have a huge impact on transaction
 confirmations (assuming equal fees for all) but once we're up at 80% then
 things start to get unpleasant. Instead of 50% of first confirmations taking
 about 7 minutes they instead take nearer to 19 minutes.

Well, this is only for first confirmations of free transaction.
A higher fee should increase your probabilities, but if you're sending
free transactions you may not care about them taking longer to be
included.

 Known: There are currently a reasonably large number of zero-fee
 transactions getting relayed and mined. If things start to slow down then
 there will be a huge incentive to delay them (or drop them altogether).

Well, maybe instant and free it's not a honest form of bitcoin
marketing and it just has to disappear.
Maybe we just need to start being more honest about pow being good for
processing micro-transactions: it is not.
Hopefully lightning will be good for that.
Free and fast in-chain transactions is something temporary that we
know will eventually disappear.
If people think it would be a adoption disaster that it happens soon,
then they could also detail an alternative plan to roll that out
instead of letting it happen.
But if the plan is to delay it forever...then I'm absolutely against.

 Known: There's a major problem looming for miners at the next block reward
 halving. Many are already in a bad place and without meaningful fees then
 sans a 2x increase in the USD:BTC ratio then many will simply have to leave
 the network, increasing centralisation risks. There seems to be a fairly
 pervasive assumption that the 300-ish MW of power that they currently use is
 going to pay for itself (ignoring capital and other operating costs).

I take this as an argument for increasing fee competition and thus,
against increasing the block size.

 Known: the orphan rate is still pretty-high even with everyone's fast
 connections. If we assume that 20M byte blocks become possible then that's
 likely to increase.

 Unknown: What are the security implications for larger blocks (this one (at
 least) can be simulated though)? For example, could large blocks with huge
 numbers of trivial transactions be used to put other validators at a
 disadvantage in a variant of a selfish mining attack? I've seen objections
 that such bad actors could be blacklisted in the future but it's not clear
 to me how. A private mining pool can trivially be made to appear like 100
 pools of 1% of the size without significantly affecting the economics of
 running that private mine.

No blacklisting, please, that's centralized.
In any case, a related known: bigger blocks give competitive advantage
to bigger miners.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase

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 to
 support over the next eleven years.

Mhmm, I hadn't thought about this. This makes sense and actually
explains the urgency on taking a decision better than anything else
I've heard.

On Thu, May 7, 2015 at 5:29 PM, Mike Hearn m...@plan99.net wrote:
 If it's not raised, then ... well, then we're in new territory entirely.
 Businesses built on the assumption that Bitcoin could become popular will
 suddenly have their basic assumptions invalidated. Users will leave. The
 technical code change would be zero, but the economic change would be
 significant.

This, on the other hand, is a non sequitur [1], another type of fallacy.
Well, several of them, actually:

- If it's not raised, then bitcoin cannot become popular
- If it's not raised, then users will leave
- Businesses built on the assumption that Bitcoin could become popular
were also assuming that it's going to be risen.

These statements may even be true, but they're no logical conclusions
even if they seem obvious to you.
I don't think those claims are strictly true, specially because they
involve predictions about what people will do.
But if they're true they require some proof or at least some explanation.

[1] http://en.wikipedia.org/wiki/Non_sequitur_(logic)#Affirming_the_consequent

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase

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 process if we think
 they make no sense.

 I guess that means me and Gavin can remove everyone else from the developer
 consensus, because we think trying to stop Bitcoin growing makes no sense.

 Do you see the problem with this whole notion? It cannot possibly work.
 Whenever you try and make the idea of developer consensus work, what you end
 up with is I believe in consensus as long as it goes my way. Which is
 worthless.

That is not what I said. Then you demonstrated that it was absurd.
That's called a straw man argument and it's a well known fallacy, it
is precisely the example of arguments that can be safely ignored.
It is an argument against my admittedly vague definition of
non-controversial change.
More importantly, I never said anything about removing anyone, I was
always talking about arguments and not people.
One person could use fallacious arguments to attack or defend a given
proposal and use perfectly valid ones in another, a person can even
mix valid and invalid arguments in the same mail.

 One thing is the Bitcoin core project where you could argue that the 5
 committers decide (I don't know why Wladimir would have any more
 authority than the others).


 Because he is formally the maintainer.

Yes, the maintainer of the Bitcoin core free software project (I
cannot stressed this enough, that can be forked by anyone), not the
president of Bitcoin the p2p network.

 Maybe you dislike that idea. It's so  centralised. So let's say Gavin
 commits his patch, because his authority is equal to all other committers.
 Someone else rolls it back. Gavin sets up a cron job to keep committing the
 patch. Game over.

 You cannot have committers fighting over what goes in and what doesn't.
 That's madness. There must be a single decision maker for any given
 codebase.

I'm sure that if they become that stupid, developers would move to a
fork of the project in no time.

 Ok, so in simple terms, you expect people to have to pay enormous fees
 and/or wait thousands of blocks for their transactions to get included
 in the chain. Is that correct?


 No. I'll write an article like the others, it's better than email for more
 complicated discourse.

Ok, thanks in advance.

 As others have said, if the answer is forever, adoption is always the
 most important thing then we will end up with an improved version of Visa.


 This appears to be another one of those fundamental areas of disagreement. I
 believe there is no chance of Bitcoin ending up like Visa, even if it is
 wildly successful. I did the calculations years ago that show that won't
 happen:

 https://en.bitcoin.it/wiki/Scalability

 Decentralisation is a spectrum and Bitcoin will move around on that spectrum
 over time. But claiming we have to pick between 1mb blocks and Bitcoin =
 VISA is silly.

Again, I didn't say any of that. My point is that a network that
becomes too centralized (like visa, that is centralized vs p2p, not
vs distributed) doesn't offer any security or decentralization
advantage over current networks (and of course I meant that could
happen with larger blocks, not 1 MB blocks).
I'm sure that's not what the proponents of the size increase want, and
I'm not defending 1 MB as a sacred limit  or anything, but my question
is where is the limit for them?
Even a limitless block size would technically work because miners
would limit it to limit the orphan rate. So no hardcoded consensus
limit on transaction volume/block size could be a valid answer to the
question what is the right consensus limit to block size? for which
there's no real right answer because there is a tradeoff between
transaction volume and centralization.

Should we maintain 1 MB forever? Probably not.
Is 20 MB a bad size? I honestly don't know.
Is this urgent? I don't think so.
Should we rush things when we don't have clear answers to many related
questions? I don't think so.

You think that it is too soon to start restricting transaction volume
in any way. You will answer why in your post.
When is the right time and what is the right limitation then?

I want to have fee competition as soon as possible, at least
temporarily. But you say that it can wait for later.
Ok, when do you think we should make that happen then?
When 20 MB are full, will that be the right time to let the fee market
develop then or will it be urgent to increase the block size again?
Should we directly remove the limit then and let miners handle it as
they want?
If so, why not now?
Maybe we can increase to 2 MB, then wait for fee competition, then
wait for 2 more subsidy halvings and then increase to 11 or 20 MB?
There's so many possibilities that I don't understand how can be
surprising that 20 

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 ;)

 Consensus has to be defined as agreement between a group of people. Who are
 those people? If you don't know, it's impossible to decide when there is
 consensus or not.

 Right now there is this nice warm fuzzy notion that decisions in Bitcoin
 Core are made by consensus. Controversial changes are avoided. I am trying
 to show you that this is just marketing. Nobody can define what these terms
 even mean. It would be more accurate to say decisions are vetoed by whoever
 shows up and complains enough, regardless of technical merit.

Yes, that's why I drafted a definition for uncontroversial change
rather than change accepted by consensus.
It will still be vague and hard to define, but consensus seems much harder.
And, yes, you're right, it is more like giving power to anyone with
valid arguments to veto hardfork changes.
But as you say, that could lead to make hardforks actually impossible,
so we should limit what constitutes a valid argument.
I later listed some examples of invalid arguments: logical fallacies,
unrelated arguments, outright lies.
Certainly I don't think technical merits should count here or that we
could veto a particular person from vetoing.
We should filter the arguments, not require an identity layer to
blacklist individuals.
We should even accept arguments from anonymous people in the internet
(you know, it wouldn't be the first time).

 Unfortunately it's hard to know what other kinds of meet-in-the-middle
 compromise could be made here. I'm sure Gavin would consider them if he
 knew. But the concerns provided are too vague to address. There are no
 numbers in them, for example:

 We need more research - how much more?

Some research at all about fee market dynamics with limited size that
hasn't happened at all.
If we're increasing the consensus max size maybe we could at least
maintain the 1MB limit as a standard policy limit, so that we can
study it a little bit (like we could have done instead of removing the
initial policy limit).

 I'm not against changing the size, just not now - then when?

I don't know yet, but I understand now that having a clearer roadmap
is what's actually urgent, not the change itself.

 I'm not wedded to 1mb, but not sure 20mb is right - then what?

What about 2 MB consensus limit and 1 MB policy limit for now? I know
that's arbitrary too.

 Full node count is going down - then what size do you think would fix that?
 100kb?

As others have explained, the number of full nodes is not the
improtant part, but how easy it is to run one.
I think a modest laptop with the average internet connection of say,
India or Brazil, should be able to run a full node.
I haven't made those numbers myself but I'm sure that's possible with
1 MB blocks today, and probably with 2 MB blocks too.

 It will make mining more centralised - how do you measure that and how much
 centralisation would you accept?

This is an excellent question for both sides.
Unfortunately I don't know the answer to this. Do you?

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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.
Here's is how it works:

The operator takes a relative_height parameter and it checks that the
nSequence of the input is lower than that parameter.

Additionally, a new check at the transaction level:

for (unsigned int i = 0; i  tx.vin.size(); i++) {
// ...
if (coins-nHeight + tx.vin[i].nSequence  nSpendHeight)
return state.Invalid(false, REJECT_INVALID,
bad-txns-non-final-input);
// ...
}

Well, this is assuming that we're only using it with heights and not timestamps.
Mark, feel free to elaborate further.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 can do that while reading the code. Usually I just start cloning,
compiling and changing things as I read, if I understand this correctly,
this change should not break the tests, if I understand this, this other
change should break the build, etc.
But again, is up to you.
On Apr 16, 2015 2:34 PM, Mike Hearn m...@plan99.net wrote:

 Hey Gabe,

 That's diving into the deep end for sure! :)

 What are some current things that are lacking in Bitcoin core? Or am I
 better off making something else for the ecosystem?

 That depends on your interests.

 Many of the highest priority tasks in Bitcoin Core are rather complicated,
 unfortunately, even for people with experience. You can consult the issue
 tracker to get a feel for it.

 Alternatively, there are lots of wallet apps out there and plenty of more
 straightforward projects on them. However they may have less of a research
 flavour.


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-04-30 Thread Jorge Timón
Well, if you're interested in learning java while learning bitcoin,
probably you should be looking at https://github.com/bitcoinj/bitcoinj
or one of its related project (like the android bitcoin wallet based
on it).
There's a getting sterted page: https://bitcoinj.github.io/#getting-started

These links my be useful too:

https://bitcoin.org/en/bitcoin-for-developers
https://bitcoin.org/en/developer-documentation


On Thu, Apr 30, 2015 at 11:35 AM, Telephone Lemien
lemienteleph...@gmail.com wrote:
 Hello,
 I'm a beginner in Bitcoin and I want to know, what are things those allo me
 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, 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 can
 do that while reading the code. Usually I just start cloning, compiling and
 changing things as I read, if I understand this correctly, this change
 should not break the tests, if I understand this, this other change should
 break the build, etc.
 But again, is up to you.

 On Apr 16, 2015 2:34 PM, Mike Hearn m...@plan99.net wrote:

 Hey Gabe,

 That's diving into the deep end for sure! :)

 What are some current things that are lacking in Bitcoin core? Or am I
 better off making something else for the ecosystem?

 That depends on your interests.

 Many of the highest priority tasks in Bitcoin Core are rather
 complicated, unfortunately, even for people with experience. You can consult
 the issue tracker to get a feel for it.

 Alternatively, there are lots of wallet apps out there and plenty of more
 straightforward projects on them. However they may have less of a research
 flavour.


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live
 exercises
 http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
 event?utm_
 source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 certain transaction. It does not
 care where in the blockchain the transaction is. Or if it's in the
 blockchain at all.

 /Kalle

 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, just
 delayed.

 Ok, this was a bad idea, since nodes would have to keep it in memory.
 Please disregard that idea...

 Kalle

 Den 27 apr 2015 14:35 skrev Kalle Rosenbaum ka...@rosenbaum.se:
 
  
   Some more use cases might be:
   Waiting in comfort:
- Send a payment ahead of time, then wander over and collect the
   goods
   after X confirmations.
  
   Authorized pickup :
- Hot wallet software used by related people could facilitate the use
   of 1 of N multisig funds.  Any one of the N wallets could collect
   goods
   and services purchased by any of the others.
 
  I like this one, because it shows the power of reusing the transaction
  data structure.
 
  
   Non-monetary gifts:
- Sender exports spent keys to a beneficiary, enabling PoP to work as
   a
   gift claim
  
   Contingent services:
- Without Bob's permission, a 3rd party conditions action on a
   payment
   made from Alice to Bob.  For example, if you donated at least .02 BTC
   to
   Dorian, you (or combining scenarios, any of your N authorized family
   members), can come to my dinner party.
 
  This is an interesting one.
 
  
   I tried out your demo wallet and service and it worked as advertised.
  
   Could the same standard also be used to prove that a transaction COULD
   BE created?  To generalize the concept beyond actual payments, you
   could
   call it something like proof of payment potential.
 
  I guess it's possible, but we'd have to remove the txid from the output,
  since there is none. This is a way of saying I'm in control of these
  addresses. The other party/parties can then verify the funds on the
  blockchain and watch those addresses for changes. Maybe there are some
  interesting use cases here. Ideas?
 
  
   Why not make these proofs permanently INVALID transactions, to remove
   any possibility of their being mined and spending everything to fees
   when used in this way, and also in cases involving reorganizations?
 
  Yes. Initially I thought it would be enough that the funds are already
  spent, but I think you're right here. Reorgs could be a problem. Worse, you
  also might want to prove 0-confirmation transactions, in which case it's a
  huge security problem. Someone might intercept the PoP and publish it on 
  the
  bitcoin network, spending all the funds. But I still would like wallets to
  be able to build/verify PoPs with little or no modifications. Could we
  possibly change the version number on the PoP to something other than 1?
  Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
  just delayed. Any suggestions here?
 
  
   I agree that PoP seems complementary to BIP70.
  
  
 
  Thank you very much for your comments!
 
  /Kalle



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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, just
 delayed.

 Ok, this was a bad idea, since nodes would have to keep it in memory.
 Please disregard that idea...

 Kalle

 Den 27 apr 2015 14:35 skrev Kalle Rosenbaum ka...@rosenbaum.se:
 
  
   Some more use cases might be:
   Waiting in comfort:
- Send a payment ahead of time, then wander over and collect the goods
   after X confirmations.
  
   Authorized pickup :
- Hot wallet software used by related people could facilitate the use
   of 1 of N multisig funds.  Any one of the N wallets could collect goods
   and services purchased by any of the others.
 
  I like this one, because it shows the power of reusing the transaction
 data structure.
 
  
   Non-monetary gifts:
- Sender exports spent keys to a beneficiary, enabling PoP to work as
 a
   gift claim
  
   Contingent services:
- Without Bob's permission, a 3rd party conditions action on a payment
   made from Alice to Bob.  For example, if you donated at least .02 BTC
 to
   Dorian, you (or combining scenarios, any of your N authorized family
   members), can come to my dinner party.
 
  This is an interesting one.
 
  
   I tried out your demo wallet and service and it worked as advertised.
  
   Could the same standard also be used to prove that a transaction COULD
   BE created?  To generalize the concept beyond actual payments, you
 could
   call it something like proof of payment potential.
 
  I guess it's possible, but we'd have to remove the txid from the output,
 since there is none. This is a way of saying I'm in control of these
 addresses. The other party/parties can then verify the funds on the
 blockchain and watch those addresses for changes. Maybe there are some
 interesting use cases here. Ideas?
 
  
   Why not make these proofs permanently INVALID transactions, to remove
   any possibility of their being mined and spending everything to fees
   when used in this way, and also in cases involving reorganizations?
 
  Yes. Initially I thought it would be enough that the funds are already
 spent, but I think you're right here. Reorgs could be a problem. Worse, you
 also might want to prove 0-confirmation transactions, in which case it's a
 huge security problem. Someone might intercept the PoP and publish it on
 the bitcoin network, spending all the funds. But I still would like wallets
 to be able to build/verify PoPs with little or no modifications. Could we
 possibly change the version number on the PoP to something other than 1?
 Maybe 2^4-1? Or a really high lock_time, but it would not make it invalid,
 just delayed. Any suggestions here?
 
  
   I agree that PoP seems complementary to BIP70.
  
  
 
  Thank you very much for your comments!
 
  /Kalle


 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-04-28 Thread Jorge Timón
Even if it's new and has not received any feedback, I think my solution to
op_maturity is quite clean.
But anyway, yes, the non-relative cltv is much simpler in design and
doesn't have to wait for the other. On the other hand, I would upgrade it
to absolute cltv like you suggested and take the current height as a
parameter to verifyScript instead of using the nLockTime as reference.
If we know we're going to use it for rcltv/op_maturity, better put add soon
rather than later, specially if that will give us a more powerful cltv.
If we don't want that height param, we can leave it out 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...@jtimon.cc wrote:
   And a new softfork rule could enforce that all new CTxIn set nHeight
   to the correct height in which its corresponding prevout got into the
   chain.
   That would remove the need for the TxOutputGetter param in
   bitcoinconsensus_verify_script, but unfortunately it is not reorg safe
   (apart from other ugly implementation details).
 
  Wait, wait, this can be made reorg-safe and more backards compatible.
  The new validation rule at the tx validation level (currently in
  main::CheckInputs()) would be

 snip

 So, seems to me that RCLTV opens up a whole rats nest of design
 decisions and compromises that CLTV doesn't. Yet CLTV itself is a big
 step forward, it's been implemented on Viacoin for the past few months
 with no issues found, and has an extremely simple and easy to audit
 implementation.

 I think I'm going to argue we implement it as-is in a soft-fork. Pieter
 Wuille's been working on a new way to handle soft-fork upgrades in the
 block nVersion field, so this would be a good opportunity to add
 something simple and well tested, and also make sure the new nVersion
 soft-fork mechanism works. Equally, doing both at the same time ensures
 we don't burn yet another version bit.

 --
 'peter'[:-1]@petertodd.org
 0e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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:
 COutPoint prevout;
 CScript scriptSig;
 uint32_t nHeight;
 }

 And a new softfork rule could enforce that all new CTxIn set nHeight
 to the correct height in which its corresponding prevout got into the
 chain.
 That would remove the need for the TxOutputGetter param in
 bitcoinconsensus_verify_script, but unfortunately it is not reorg safe
 (apart from other ugly implementation details).

Wait, wait, this can be made reorg-safe and more backards compatible.
The new validation rule at the tx validation level (currently in
main::CheckInputs()) would be

for (unsigned int i = 0; i  tx.vin.size(); i++) {
// ...
if (tx.vin.nHeight + 100  tx.nLockTime)
return state.Invalid(false, REJECT_INVALID,
bad-txns-vin-height-reorg-unsafe);
if (coins-nHeight  tx.vin.nHeight)
return state.Invalid(false, REJECT_INVALID,
bad-txns-vin-height-false);
// ...
}

Existing transactions that have used the deprecated CTxIn::nSequence
for something else will be fine if they've used low nSequences.
The only concern would be breaking some colored coins kernels, but
there's many others implemented that don't rely on CTxIn::nSequence.

Transactions that want to use OP_MATURITY just have to set the
corresponding CTxIn::nHeight and CTransaction::nLockTime properly.
This way op_maturity wouldn't require anything from the utxo and the
final interface could be:

 int bitcoinconsensus_verify_script(const unsigned char* scriptPubKey,
unsigned int scriptPubKeyLen,
const unsigned char* txTo,
unsigned int txToLen,
unsigned int nIn, unsigned int nHeight,
unsigned int flags,
secp256k1_context_t* ctx,
bitcoinconsensus_error* err);

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 to distinguish it from RCLTV?

 3) GET_TXOUT_HEIGHT/TIME diff ADD CLTV

 To be reorg safe GET_TXOUT_HEIGHT/TIME must fail if minimum age 
 COINBASE_MATURITY. This can be implemented by comparing against
 nLockTime.

Mhmm, interesting.

 All three possibilities require us to make information about the
 prevout's height/time available to VerifyScript(). The only question is
 if we want VerifyScript() to also take the current block height/time - I
 see no reason why it can't. As for the mempool, keeping track of what
 transactions made use of these opcodes so they can be reevaluated if
 their prevouts are re-organised seems fine to me.

I'm totally fine with changing the interface to:

 int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo
  , unsigned int txToLen, unsigned nHeight,
unsigned int nIn, unsigned int
flags, bitcoinconsensus_error* err);

I prefer op_maturity over RCLTV and there are also gains for absolute
CLTV as you explain later.
When you validate the script inputs of a transaction you already have
a height, either the real final nHeight in ConnectBlock and the miner,
or nSpendHeight in AcceptToMemoryPool.
The costs are meaningless in my opinion, specially when we will
already have to change the interface to add libsecp256k1's context.

I'm infinitely more worried about the other assumption that the 3
solutions are already making.
Changing to

 int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo
  , unsigned int txToLen, const CCoinsViewCache inputs,
unsigned int nIn, unsigned int
flags, bitcoinconsensus_error* err);

Is simply not possible because CCoinsViewCache is a C++.
You could solve it in a similar way in which you could solve that
dependency for VerifyTransaction.
For example:

typedef const CTxOut (*TxOutputGetter)(const uint256 txid, uint32_t n);

  int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo
  , unsigned int txToLen, TxOutputGetter utxoGetter,
unsigned int nIn, unsigned int
flags, bitcoinconsensus_error* err);

Of course, this is assuming that CTxOut becomes a C struct instead of
a C++ class and little things like that.
In terms of code encapsulation, this is still 100 times uglier than
adding the nHeight so if we're doing it, yes, please, let's do both.

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:
COutPoint prevout;
CScript scriptSig;
uint32_t nHeight;
}

And a new softfork rule could enforce that all new CTxIn set nHeight
to the correct height in which its corresponding prevout got into the
chain.
That would remove the need for the TxOutputGetter param in
bitcoinconsensus_verify_script, but unfortunately it is not reorg safe
(apart from other ugly implementation details).

So, in summary, I think the new interface has to be something along these lines:

  int bitcoinconsensus_verify_script(const unsigned char
*scriptPubKey, unsigned int scriptPubKeyLen,
const unsigned char *txTo,
unsigned int nIn,
unsigned int txToLen,
TxOutputGetter utxoGetter, unsigned nHeight, secp256k1_context_t *ctx
unsigned int flags,
bitcoinconsensus_error* err);

 Time-based locks
 

 Do we want to support them at all? May cause incentive issues with
 mining, see #bitcoin-wizards discussion, Jul 17th 2013:

 https://download.wpsoftware.net/bitcoin/wizards/2013/07/13-07-17.log

I'm totally fine not supporting time-based locks for the new operators.
Removing them from the regular nLockTime could be more complicated but
I wouldn't mind either.
Every time I think of a contract or protocol that involves time, I do
it in terms of block heights.
I would prefer to change all my clocks to work in blocks instead of
minutes over changing nHeights for timestamps in any of those
contracts.

 --
 'peter'[:-1]@petertodd.org
 015e09479548c5b63b99a62d31b019e6479f195bf0cbd935

 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop 

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
the tx ID.

On Sat, Apr 18, 2015 at 4:49 PM, s7r s...@sky-ip.org wrote:
 Understood. That is unfortunate, but not the end of the world. If you
 could please give feedback also to these last comments / questions:

 How far are we at this moment from BIP62? Can an user send a
 non-malleable tx now, if enforces some additional rules?

 As for the security of the system, it does not fully rely on txids being
 non malleable, but see this quote from my previous email:

 [QUOTE]
 I am trying to build a bitcoin contract which will relay on 3 things:
 - coinjoin / txes with inputs from multiple users which are signed by
 all users after they are merged together (every user is sure his coins
 will not be spent without the other users to spend anything, as per
 agreed contract);
 - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
 before the inputs being spent are broadcasted/confirmed, using the txid
 provided by the user before broadcasting it. Malleability hurts here.
 - P2SH

 Another thing I would like to confirm, the 3 pieces of the bitcoin
 protocol mentioned above will be supported in _any_ future transaction
 version or block version, regardless what changes are made or features
 added to bitcoin core? The contract needs to be built and left unchanged
 for a very very long period of time...
 [/END QUOTE]

 Can you comment on the quote please?

 So, basically transaction malleability could affect the system in the
 way that a pre-signed tx which offers the insurance and which is sent to
 the user before the user sends the coins (spending user's coins back to
 him after a certain period of time) could be invalidated. The insurance
 tx signature will still be good, but invalid overall since the input
 (txid) being spent does not exist (was altered / modified). The coins
 won't be stolen or lost, but a new tx needs to be signed with the
 altered (new) txid, for the system to work.

 So, an user creates a transaction TX1 sending the coins to the server
 but does not broadcast it. Instead, he provides the txid of TX1 to the
 server. Server generates another transaction TX2 which spends TX1 back
 to the user, with an nLockTime. User checks and if everything ok
 broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2
 will become invalid (since it will be spending an inexistent input), and
 the server will need to re-create and sign TX2 with the new
 (altered/modified) txid of TX1, as per agreed contract. Should the
 server disappear after user broadcasts TX1 and before the
 altered/modified txid of TX1 gets confirmed, user's coins are forever
 locked. It is true that no third party can benefit from this type of
 attack, only the user will result with coins locked, but it is something
 which could be used by competition to make a service useless / annoying
 / too complicated or less safe to use.

 How could I mitigate this?

 Thanks you for your time and help.

 On 4/17/2015 12:02 PM, Pieter Wuille wrote:
 Anyone can alter the txid - more details needed. The number of altered
 txids in practice is not so high in order to make us believe anyone can
 do it easily. It is obvious that all current bitcoin transactions are
 malleable, but not by anyone and not that easy. At least I like to
 think so.

 Don't assume that because it does not (frequently) happen, that it
 cannot happen. Large amounts of malleated transactions have happened in
 the past. Especially if you build a system depends on non-malleability
 for its security, you may at some point have an attacker who has
 financial gain from malleation.

 From your answer I understand that right now if I create a transaction
 (tx1) and broadcast it, you can alter its txid at your will, without any
 mining power and/or access to my private keys so I would end up not
 recognizing my own transaction and probably my change too (if my systems
 rely hardly on txid)?

 In theory, yes, anyone can alter the txid without invalidating it,
 without mining power and without access to the sender's private keys.

 All it requires is seeing a transaction on the network, doing a trivial
 modification to it, and rebroadcasting it quickly. If the modifies
 version gets mined, you're out of luck. Having mining power helps of course.

 After BIP62, you will, as a sender, optionally be able to protect others
 from malleating. You're always able to re-sign yourself.

 --
 Pieter


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process in accordance with the BPMN 2 standard
 Learn Process modeling best practices with Bonita BPM through live exercises
 

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 and will hopefully
 clear some of your doubts.
 The signer of TX1 will always be able to change the signature and thus
 the tx ID.

 On Sat, Apr 18, 2015 at 4:49 PM, s7r s...@sky-ip.org wrote:
 Understood. That is unfortunate, but not the end of the world. If you
 could please give feedback also to these last comments / questions:

 How far are we at this moment from BIP62? Can an user send a
 non-malleable tx now, if enforces some additional rules?

 As for the security of the system, it does not fully rely on txids being
 non malleable, but see this quote from my previous email:

 [QUOTE]
 I am trying to build a bitcoin contract which will relay on 3 things:
 - coinjoin / txes with inputs from multiple users which are signed by
 all users after they are merged together (every user is sure his coins
 will not be spent without the other users to spend anything, as per
 agreed contract);
 - pre-signed txes with nLockTime 'n' weeks. These txes will be signed
 before the inputs being spent are broadcasted/confirmed, using the txid
 provided by the user before broadcasting it. Malleability hurts here.
 - P2SH

 Another thing I would like to confirm, the 3 pieces of the bitcoin
 protocol mentioned above will be supported in _any_ future transaction
 version or block version, regardless what changes are made or features
 added to bitcoin core? The contract needs to be built and left unchanged
 for a very very long period of time...
 [/END QUOTE]

 Can you comment on the quote please?

 So, basically transaction malleability could affect the system in the
 way that a pre-signed tx which offers the insurance and which is sent to
 the user before the user sends the coins (spending user's coins back to
 him after a certain period of time) could be invalidated. The insurance
 tx signature will still be good, but invalid overall since the input
 (txid) being spent does not exist (was altered / modified). The coins
 won't be stolen or lost, but a new tx needs to be signed with the
 altered (new) txid, for the system to work.

 So, an user creates a transaction TX1 sending the coins to the server
 but does not broadcast it. Instead, he provides the txid of TX1 to the
 server. Server generates another transaction TX2 which spends TX1 back
 to the user, with an nLockTime. User checks and if everything ok
 broadcasts TX1. In case the txid of TX1 will be altered/modified, TX2
 will become invalid (since it will be spending an inexistent input), and
 the server will need to re-create and sign TX2 with the new
 (altered/modified) txid of TX1, as per agreed contract. Should the
 server disappear after user broadcasts TX1 and before the
 altered/modified txid of TX1 gets confirmed, user's coins are forever
 locked. It is true that no third party can benefit from this type of
 attack, only the user will result with coins locked, but it is something
 which could be used by competition to make a service useless / annoying
 / too complicated or less safe to use.

 How could I mitigate this?

 Thanks you for your time and help.

 On 4/17/2015 12:02 PM, Pieter Wuille wrote:
 Anyone can alter the txid - more details needed. The number of altered
 txids in practice is not so high in order to make us believe anyone can
 do it easily. It is obvious that all current bitcoin transactions are
 malleable, but not by anyone and not that easy. At least I like to
 think so.

 Don't assume that because it does not (frequently) happen, that it
 cannot happen. Large amounts of malleated transactions have happened in
 the past. Especially if you build a system depends on non-malleability
 for its security, you may at some point have an attacker who has
 financial gain from malleation.

 From your answer I understand that right now if I create a transaction
 (tx1) and broadcast it, you can alter its txid at your will, without any
 mining power and/or access to my private keys so I would end up not
 recognizing my own transaction and probably my change too (if my systems
 rely hardly on txid)?

 In theory, yes, anyone can alter the txid without invalidating it,
 without mining power and without access to the sender's private keys.

 All it requires is seeing a transaction on the network, doing a trivial
 modification to it, and rebroadcasting it quickly. If the modifies
 version gets mined, you're out of luck. Having mining power helps of course.

 After BIP62, you will, as a sender, optionally be able to protect others
 from malleating. You're always able to re-sign yourself.

 --
 Pieter


 --
 BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
 Develop your own process

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
community can define N (which is not accepted by bitcoin due to the new
rules) as the genesis block for bitcoinB for the purposes of chain ID. As
said forking bitcoins and  bitcoinsB with the same owners doesn't make much
sense to me. If you're creating a new currency you can just as well define
a new chain. If you want to start an initial utxo giving the new coins to
bitcoin holders...I still don't see the point, but you can also do that in
a new chain.

In summary, your example is not a good reason not to adopt a hash of the
genesis block as chain ID.
On Mar 14, 2015 5:22 PM, Isidor Zeuner cryptocurrenc...@quidecco.de
wrote:

  That was essentially what we did in the end, we replaced the network
  identifier (main/test) with the genesis block hash. The result is
  never going to accidentally work with Bitcoin Core (nor vice-versa), but
  is readily extensible to any other altcoins that want to use the
  specification without requiring any sort of central registry.
 

 Interesting approach, and I also think that requiring a central
 registry would be potentially harmful.

 However, I think it might not be adequate to think of the network
 identifier as being congruent with the genesis block hash. In the
 theoretical case of the blockchain being continued on two forked
 chains (with two communities which prefer one of the chains each),
 clients would not be prevented from interpreting messages on the wrong
 chain.

 Best regards,

 Isidor


 --
 Dive into the World of Parallel Programming The Go Parallel Website,
 sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for
 all
 things parallel software development, from weekly thought leadership blogs
 to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 clarified that the concept was referred to as scorched earth
http://sourceforge.net/p/bitcoin/mailman/message/32264039/

Like I said I don't like the name and would prefer stag hunting
which is more formal and precise.
Some people seem to use the same term for the potential undesirable
consequences of widely deployed replace-by-fee policies.
I'm not sure that concept deserves its own term.

 All payment processors AFAIK process transactions through some scoring
 system, then accept 0-conf transactions for payments.

 This isn't some theoretical exercise.  Like it or not many use
 insecure 0-conf transactions for rapid payments.  Deploying something
 that makes 0-conf transactions unusable would have a wide, negative
 impact on present day bitcoin payments, thus scorched earth

And maybe by maintaining first seen policies we're harming the system
in the long term by encouraging people to widely deploy systems based
on extremely weak assumptions.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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  payment protocol.
Even if that protocol didn't existed or didn't worked, replace-by-fee
is purely part of a node's policy, not part of consensus.
From the whitepaper, 0 conf transactions being secure by the good will
of miners was never an assumption, and it is clear to me that the
system cannot provide those guaranties based on such a weak scheme. I
believe thinking otherwise is naive.
As to consider non-standard policies an attack to bitcoin because
that's not how bitcoin used to work, then I guess minimum relay fee
policies can also be considered an attack to bitcoin on the same
grounds.
Lastly, first-seen-wins was just a simple policy to bootstrap the
system, but I expect that most nodes will eventually move to policies
that are economically rational for miners such as replace-by-fee.
Not only I disagree this will be the end of bitcoin or will push
the price of the btc miners are mining down, I believe it will be
something good for bitcoin.
Since this is apparently controversial I don't want to push for
replace-by-fee to become the new standard policy (something that would
make sense to me). But once the policy code is sufficiently modular as
to support several policies I would like bitcoin core to have a
CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no
policy checks at all).
One step at a time I guess...


On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes ho...@hozed.org wrote:
 On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote:


 On 02/15/2015 11:25 PM, Troy Benjegerdes wrote:
 
  Most money/payment systems include some method to reverse or undo
  payments made in error. In these systems, the longer settlement
  times you mention below are a feature, not a bug, and give more
  time for a human to react to errors and system failures.
 

 Settlement has to be final somewhere. That is the whole point of it.
 Transfer costs in current electronic payment systems are a direct
 consequence of their non-finality. That's the point Satoshi was making
 in the introduction to the whitepaper: With the possibility of
 reversal, the need for trust spreads.

 The problem with that statement is I trust a merchant that I went into
 a store and made a payment with personally more than I trust the firmware
 on my hard drive [1].

 The attack surface of devices in your computer is huge. A motivated attacker
 just needs to get an intern into a company that makes some kind of component
 or system that's in your computer, cloud server, hardware wallet, or what
 have you that has firmware capable of reading your private keys.

 With the possibility of mass trojaned hardware, if we are going to trust
 the system, it must somehow allow reversal through a human-in-the-loop.

 There is nothing wrong with having reversible mechanisms built on top
 of Bitcoin, and indeed it makes sense for most activity to happen at
 those higher layers. It's easy to build things that way, but
 impossible to build them the other way: you can't build a
 non-reversible layer on top of a reversible layer.

 We built 'reliable' TCP on top of unreliable ethernet networks. My experience
 with networking was if you tried to guarantee message delivery at the lowest
 level, the system got exceedingly complicated, expensive, and brittle.

 Most applications, in particular paying someone you already trust, are quite
 happy running on reversible systems, and in some cases more reliable and
 lower risk. (carrying non-reversible cash is generally considered risky)

 The problem is that if the base currency is assumed to be non-reversible,
 then it's brittle and becomes 'too big to fail'.

 Where the blockchain improves on everything else is in transparency. If you
 reverse transactions a lot, it will be obvious from an analysis. I would much
 rather deal with a known, predictable, and relatively continous transaction
 reversal rate (percentage) than have to deal with sudden failures where
 some anonymous bad actor makes off with a fortune.

 We already have zero-conf double-spend transaction reversal, why not 
 explicitly
 extend that a little in a way that senders and receivers have a choice to
 use it, or not?


 [1] 
 http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216

 --
 Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
 from Actuate! Instantly Supercharge Your Business Reports and Dashboards
 with Interactivity, Sharing, Native Excel Exports, App Integration  more
 Get technology previously reserved for billion-dollar corporations, FREE
 http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
 

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
 dialects of Haskell, Lisp, Smalltalk and a bunch of more obscure languages
 like Scala, Kotlin, Ceylon, etc.

 It makes more sense to talk about bindings to particular runtimes these
 days, rather than particular languages.

Oh, I didn't knew that. Thanks for the clarification.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 separately hosted project 
 only using the C interface of the libconsensus library.

He didn't said a project for all possible language bindings, just
java bindings. Other languages' bindings would be separate projects.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=190641631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 service rules, wallet and RPC server.

Right now libconsensus' only dependency is openSSL. Most of the
testing in libsecp256k1 has been in signing rather than verifying
signatures (please, anyone with more knowledge in the library don't
hesitate to correct me or clarify things). But eventually openSSL will
be completely replaced by libsecp256k1.
It does not store anything, 0.1 is just a dynamic library with a c API
to a single function: VerifyScript().
This function saves the hassle of reimplementing signature checking
(which is a really hard part) and reimplementing an interpreter that
must function in exactly the same way in many as many other nodes with
different software and/or hardware.
Guido van Rossum can say some behaviours in python the language are
not specified, so it is ok if cpython and pypy do different things,
they're still both running python which is more abstract than any of
its implementation.
But a consensus system like bitcoin doesn't have the luxury of leaving
consensus rules unspecified. And the simplest way to fully specify a
language interpreter is by implementing it.
But coupling the consensus rules specification with a bigger project
like bitcoin core can result in implementation details of that bigger
project accidentally and unexpectedly becoming consensus rules. This
is what happened with bdb and nobody wants that to happen again,
that's the whole point.
Note that many parts of the bitcoin protocol (like the p2p messages)
are NOT part of the consensus rules.
You can have a look at
https://github.com/jtimon/bitcoin/commits/consensus2 and maybe you
would be surprised about how small they actually are. This branch is
incomplete and still a mess that needs to be cleaned up. And none of
that is included in libconsensus yet.
I was planning on writing a post here asking for feedback on the
interfaces for these higher level checks. I'm just putting the code
together in the same module, but obviously class CCoinsViewCache
cannot be an argument in functions of a c API.

 The Core code base is unfriendly to feature extensions because of its
 criticality, legacy design and ancient technology. It is also a commodity
 that the ecosystem takes for granted and free.

 I honestly admire the core team that works and progresses within these
 limits and perception.

 I am not willing to work within the core’s legacy technology limits. Does it
 mean I am dicking around? I think not.
 It was my way to go down the rabbit hole by re-digging it and I created
 successful commercial products on the way.

Nobody is attacking alternative implementations. This tool was created
mostly with alternative implementations in mind.
So input from them it's very welcomed on how to continue libconsensus
(or of course correct any flaws in verifyScript if there's any).
I just wanted to wait to have some more code to make things easier to
explain (and have a clearer idea of it myself).
There's a more limited branch on next steps for libconsensus in #5669.

 It is entirely rational for me to focus on innovation that uses the core as
 a border router for this block chain.

Sure, I think he is complaining that at the moment that's probably the
only safe way to operate with alternative implementations and still
have full node guarantees.

 I am rather thankful for the ideas of the side chains, that enable
 innovation that is no longer measured on unapologetic compatibility with a
 given code base, but its services to end user.

Sidechains are completely orthogonal to this discussion and, in fact,
it would be good to have libconsensuses for sidechains too, since
their nodes also need to come to consensus.

--
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 includes pay-to-fee transactions in a block, those fees
 could be claimed by another miner in the case the first miner's block
 is orphaned.

 Inputs to a generation transaction can not be similarly poached.

 That difference makes some services possible that would can not be
 safely achieved with pay-to-fee transactions.

What services?
I must be missing something obvious about the motivation.
I understand the difference between paying to myself only when I mine
the next block and offering fees to whoever mines this tx.
But how does allowing miners to pay to themselves in this way help
with security and future lower subsidies at all?

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 be possible today with vanilla bitcoin using SIGHASH_SINGLE if only
 the protocol supported multiple validated assets (which it could, but
 doesn't). Rather straightforward further extensions to the protocol would
 enable market participants to use a wider class of orders, as well as
 enable the buyer rather than the seller to dictate order sizes via partial
 redemption, as we demonstrate in our Freimarkets paper.

 Do you realise that all those Freimarket's uses are either based on
 proof-of-publication, or insecure due to sybil attacks?

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.
Bob is willing to pay up to 200 Bs for 1 A.

Let's assume a proof of publication system first, in which the
execution price is the mean between bid and ask.
Alice publishes her order.
Bob could publish his order at price 200 Bs and the order would
execute at 150 Bs.
But after seeing Alice's order he knows he doesn't need to pay that
much, so he publishes and order buying for 100 Bs.

Alice gets 100 Bs (what she signed she wanted) and Bob pays less than
he was wiling to pay, he pays 100 Bs. Everybody happy.

Now let's assume native assets and sighash_single.

Alice publishes her order (out of band, using various channels).
Bob could publish his order at price 200 Bs and then a miner would
execute at 100 Bs for Alice, at 200 Bs for Bob and pocket 100 Bs as
mining fees.
But after seeing Alice's order he knows he doesn't need to pay that
much, so he publishes and order buying for 100 Bs.

Again, Alice gets 100 Bs (what she signed she wanted) and Bob pays pays 100 Bs.
The main difference is that Alice didn't had to pay a fee to publish
her binding order.

Now let's try to articulate your concerns.
Your concern is that Carol, isolates Bob preventing him from seeing
Alice's order.
Then maybe Bob publishes his own order at 200 Bs.
If Carol sees both orders while preventing the other participants from
seeing them, she can build a tx in which Alice sells at 100, Bob buys
at 200, and Carol pockets the difference.
But...any smart miner will replace Carol's address with his own when
processing the trade, so Carol cannot win this way.

Another thing Carol can do is to buy the A herself for 100 Bs, leaving
Bob without them.
If Alice cares about Bob getting the deal instead of Carol she can do
two things:
1) Establish a direct communication channel with Bob
2) Move to a proof of publication system and start paying fees for
publishing binding orders.

So again, what's the advantage that proof-of-publication provides TO
ALICE so that she will be so eager to pay the higher costs to get the
same deal?
If this example is not enough to be able to explain the advantage of
proof-of-publication markets feel free to write a more complex one.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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.
 Bob is willing to pay up to 200 Bs for 1 A.

 Let's assume a proof of publication system first, in which the
 execution price is the mean between bid and ask.
 Alice publishes her order.
 Bob could publish his order at price 200 Bs and the order would
 execute at 150 Bs.
 But after seeing Alice's order he knows he doesn't need to pay that
 much, so he publishes and order buying for 100 Bs.

 Alice gets 100 Bs (what she signed she wanted) and Bob pays less than
 he was wiling to pay, he pays 100 Bs. Everybody happy.

 Now let's assume native assets and sighash_single.

 Incidentally, SIGHASH_SINGLE is just as usable in embedded consensus;
 it's not specific to native assets.

 So again, what's the advantage that proof-of-publication provides TO
 ALICE so that she will be so eager to pay the higher costs to get the
 same deal?

 Like I said the last time this issue was discused on the mailing list,
 it's silly to think the seller of an asset starts off with a specific
 price they want to sell it at and is happy no matter what happens or how
 it gets fufilled. In the real world sellers and buyers want to know
 they're connected to actual sellers and buyers - not sybil attackers
 trying to shave off a margin for themselves - and are willing to pay a
 premium for that. Note all the hatred and vitrol directed towards
 high-frequency traders...

And like last time we discussed this on the mailing list my opinion
differs from yours.
You talk about real world sellers and buyers but ignore Alice the
seller and Bob the buyer in my example.
You failed to explain how sybil attackers (Carol) get all those
margins. In my example I claim miners get them, what am I missing?
How is the same example with a proof-of-publication market any better?
Miners can reorder the orders with proof of publication too.
If getting orders into mined blocks faster has an advantage miners can
charge privileged traders for privileged connections (just like it
happens today with perfectly fair centralized markets today that
feature the high-frequency trading you mention).
They could even charge for moving transactions around within the same
block if that has any effect on the execution rules.
I prefer that miners can get the difference between bids and asks
directly to compensate for their hashing power.

 How *much* of a premium is an interesting question, and depends a lot on
 the specific scenario. For instance I fully expect to see a whole
 variety of mediums become used for the proof-of-publication needed,
 ranging from directly on a major blockchain to minor/less secure
 blockchains like Bitmessage over treechains to centralized-but-audited
 proof-of-publication schemes - AKA centralized exchanges - to standard
 exchanges. Point is, the concept of proof-of-publication makes these
 tradeoffs and options available and lets end-users pick the right one
 for their needs.

The point is that there's more models for p2p markets beyond those
that require proof of publication for their orders, and you're
claiming that only those using proof of publication are secure.
That's incorrect.

 Accurate unbiased price information is worth money.

Can you define Accurate unbiased price information?

 In systems that
 allow third-parties to republish asset bids and offers we'll even see
 third-parties republishing bids and offers from less secure systems to
 more secure systems to get better price discovery.

Traders want to trade. The primary function of markets is exchange,
not price discovery.

 If this example is not enough to be able to explain the advantage of
 proof-of-publication markets feel free to write a more complex one.

 I gotta ask, have you actually run the design and tradeoffs of
 Friemarket's past actual finance types? I have, and it's remarkable how
 excited many of them are about cryptographically provable fair price
 discovery.

Provably fair price discovery is probably impossible. But I can
imagine how many people could get excited about such a technology.
Can you formally define what you mean by this?
You see, fair implies morality and therefore it's a very subjective
term, so it's not obvious to me what you may mean by that.


 --
 'peter'[:-1]@petertodd.org
 02661192e72bdc83e6c8101371520159531301aa1437cc2c

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu

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 need to broadcast more data then we're not talking about
timestamping anymore, but rather proof of publication.
Unfortunately (and as it has been already mentioned) many applications
don't need proof of publication and yet they are just using the
blockchain as a convenient transport mechanism, but that's highly
inefficient.
It's like if you sent all your mails to all the existing email
addresses with the metadata to be read by: destinat...@yourhost.com.
It wouldn't make any sense and it wouldn't scale.
A url definitely looks like something that doesn't belong in the chain.

--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 configure their own policy.
In my opinion the best we can do is to make it easier for miners to
implement their own policies by abstracting out those parts of the
code. Pull requests like #5071 and #5114 are steps in that direction.
So if you're interested in having more miners accepting 80 bytes
OP_RETURN transactions, I suggest you invest some time reviewing and
testing those PRs.
Although this wasn't its main purpose, separating script/standard was
also a little step in the same direction.

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-11-16 Thread Jorge Timón
As an aside, the decision to make it 40 bytes made sense because it is
enough for timestamping. In fact, you can do cheaper and even secret
(and thus impossible to censor by miners) timestamping using
pay-to-contract [1], which uses exactly 0 extra bytes in your
transaction and the blockchain.
I remember people asking in #bitcoin-dev Does anyone know any use
case for greater sizes OP_RETURNs? and me answering I do not know of
any use cases that require bigger sizes.
I'm aware that so called proof of publication is not equivalent to
timestamping, but I wasn't aware at the moment (and I don't think it's
very interesting but that's obviously only my opinion, embedded
systems developers will disagree).

[1] Here's a video explaining pay-to-contract in the context of
invoicing as a use case: https://www.youtube.com/watch?v=qwyALGlG33Q
Here's a generic working implementation:
https://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 is that
 policies depend on miners. Unfortunately most miners and pools are
 quite apathetic when it comes to configure their own policy.
 In my opinion the best we can do is to make it easier for miners to
 implement their own policies by abstracting out those parts of the
 code. Pull requests like #5071 and #5114 are steps in that direction.
 So if you're interested in having more miners accepting 80 bytes
 OP_RETURN transactions, I suggest you invest some time reviewing and
 testing those PRs.
 Although this wasn't its main purpose, separating script/standard was
 also a little step in the same direction.

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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).

 http://blockstream.com/sidechains.pdf


 Haven't seen any material discussion of this paper in this mailing list, so
 I'll start.
 (Otherwise, I've seen Peter Todd's reaction on reddit.)

 This paper fails to demonstrate that sidechains are anything more than a
 wishful thinking.
 It can be distilled down to this:
 We want such and such features, hence we'll use DMMS, the same thing
 Bitcoin uses, thus it will be secure!
 Um, no.
 Alt-coins also use DMMS, but aren't as secure as Bitcoin.

 So DMMS does not work by itself, it is a mechanism to secure a blockchain
 using economic incentives.
 The sidechains paper does not mention this, as far as I can tell.

 In my opinion, this is not acceptable. If you're making a proposal, you need
 to describe what conditions are required for it to work.

From the introduction [...]Because signers prove computational work,
rather than proving secret knowledge as
is typical for digital signatures, we refer to them as miners. To
achieve stable consensus on the
blockchain history, economic incentives are provided where miners are
rewarded with fees and
subsidies in the form of coins that are valuable only if the miners
form a shared valid history,
incentivising them to behave honestly.[...]

Ignoring altrustic miners, the irreversibility of a DMMS chain
obviously depends on the rewards received by miners on that chain.
Nobody is claiming that sidechains will be as secure bitcoin, any 2
way pegged assets is always more secure (probably too vague of a
term in this context) in its original chain.

 Authors are clearly aware of the problem and mention it in section 6 Future
 directions 6.1. Hashpower attack resistance.
 The problem is they do not make it clear that the proposal just makes no
 sense until this is solved.

Since all seigniorage from Bitcoin's initial distribution is spent on
mining subsidies for the main chain, it is not available to subsidize
sidechains too. Thus sidechains, in principle, reward their miners
with the same Bitcoin will use in the future: only transaction fees.
Since some people claim that won't be enough (is not always clear to
me if they believe that won't be enough for sidechains or also for
bitcoin when the subsidies are gone), we included this section with
other ideas we have explored to further. Some of them, like
time-shifted fees could be interesting for Bitcoin itself in the
future.

 It doesn't help that the paper itself tries to sweep the problem under the
 rug and has misleading statements.
 Particularly, I'm talking about section 4.2. Fraudulent transfers:

 Reorganisations of arbitrary depth are in principle possible, which could
 allow an attacker to
 completely transfer coins between sidechains before causing a reorganisation
 longer than the contest
 period on the sending chain to undo its half of the transfer. ... If the
 attacker is allowed to return the transferred coins to  the original
 chain, he would increase the number of coins in his possession at the
 expense of other users of the sidechain.
 Before discussing how to handle this, we observe that this risk can be made
 arbitrarily small by
 simply increasing the contest period for transfers.

 Wow, really? Is this risk stochastic?

 The first sentence implies that attacker is able to cause a reorganization
 of an arbitrary depth, but the rest of the section implies that
 reorganizations are a naturally occurring phenomenon.

Reorganizations are both a naturally occurring phenomenon and
something that an attacker may cause to revert history.
Section 11. Calculations of the Bitcoin whitepaper gives you this
formula (in C code):

#include math.h
double AttackerSuccessProbability(double q, int z)
{
double p = 1.0 - q;
double lambda = z * (q / p);
double sum = 1.0;
int i, k;
for (k = 0; k = z; k++)
{
double poisson = exp(-lambda);
for (i = 1; i = k; i++)
poisson *= lambda / i;
sum -= poisson * (1 - pow(q / p, z - k));
}
return sum;
}
Also says Given our assumption that p  q, the probability drops
exponentially as the number of blocks the
attacker has to catch up with increases.

In this case, the contest period determines z, the number of blocks
the attacker has to catch up from the honest chain.
So the longer the contest period is, the harder it is to succeed with
a fraudulent transfer.
For example, if a given sidechain chooses 52560 as the contest period
(1 year assuming 10 min blocks), it will be very hard for an attacker
to produce a fake alternative longest-than-the-last-year-of-history
fork to steal coins.
A sidechain with such an extreme contest period would probably not be
very practical though, since honest users would have to wait more than

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 requirement here,
 as miner will get bitcoins which aren't in any way connect to sidechain he
 have wrecked.  Thus there is no incentive to behave honestly.

But if the majority of the sidechain miners keep working on the honest
chain, anyone can submit a reorg proof during the contest period that
invalidates this unlockment on the parent chain.
Honest sidechain miners will get rewarded in the sidechain, and those
rewards will only be valuable if they form a shared valid history.

 Whether it is enough depends on a variety of factors, including existence of
 other chains miner can mine.
 You cannot assume that it is the same situation as with a simple
 single-chain model.

This is correct. There's many variables at play.

 E.g. imagine 1000 BTC were moved to a sidechain. Miners can keep mining
 bitcoins as usual, and in parallel work on an SPV proof to claim these 1000
 BTC. (I assume that merged-mining is allowed.)
 In this case the amount of fees which miners could collect by honest mining
 on the sidechain is irrelevant, as long as it is smaller than 1000 BTC.

As explained many times, sidechains and merged mining are orthogonal:
pegged sidechains don't need to use merged mining just as merged
mining altchains don't need to be sidechains.
Anyway, I think you're somehow assuming that deciding to mine against
the sidechain instead of mining for its rewards.
This is simply not true. No matter how big the attack incentive is, if
you're assuming my 52560 contest period example and that the attacker
doesn't control the majority of the hashing power on the sidechain,
the probability of achieving a one-year reorg is negligible. In the
meantime honest nodes are getting some reward, let's say 0.1 BTC per
block. That's 5256 btc/year to the honest nodes vs 0 btc/year for the
attacker.
If the attacker controls, say, 10% of the network, he's losing 525.6
btc/year in opportunity costs for an extremely small chance of getting
1000 btc.

 This is quite different from attacks which can be performed on vanilla
 Bitcoin (see below), so I don't think you can say that the security model is
 the same.

We're not claiming that the security model is the same, we just
compare it to Bitcoin's because it's similar in many senses.

 Also says Given our assumption that p  q, the probability drops

 exponentially as the number of blocks the
 attacker has to catch up with increases.


 Yes, but that doesn't apply to reorganizations which attacker might cause
 intentionally.

Yes, that's precisely the kind of reorganizations the BITCOIN
WHITEPAPER is talking about in section 11 Calculations:
reorganizations caused intentionally by an attacker. Please read it
again.
q_z = probability THE ATTACKER will ever catch up from z blocks behind.

 Hence I think it was disingenuous to include these two very different treats
 into one section:
 it sounds like you claim that attacker-induced reorganizations are unlikely,
 while it isn't the case.

If it sounds to you like we're claiming that attacker-induced
reorganizations are not likely, maybe we could have expressed it some
other way. That was certainly not the intention.
That's not true for Bitcoin itself and that's not what we're claiming.

 So the longer the contest period is, the harder it is to succeed with
 a fraudulent transfer.


 Yes, but harder isn't same as unlikely.

Exponentially harder with the number of blocks is good enough for me.

 Another problem with this section is that it only mentions reorganizations.
 But a fraudulent transfer can happen without a reorganization, as an
 attacker can produce an SPV proof which is totally fake. So this is not
 similar to double-spending, attacker doesn't need to own coins to perform an
 attack.

That would be a reorganization too, you can't create a completely fake
history for a sidechain, the attacker will share some of the chain's
history.
Yes, the attacker can create an SPV proof of a fake chain and in that
sense, this is different from a regular double-spend.
If honest miners control the majority of the hashing power, they will
produce a valid chain longer than the fake chain. And then anyone can
use that reorg proof to stop the attacker before the contest period.
You see, SPV security is not the same as SPV security with more
than 52560 confirmations of the transaction I'm receiving.

 I hope this clarifies our assumptions.

 Yep, thanks. It looks like you assume that sidechain security will be
 similar to Bitcoin security in the long term.
 Now quite the assumptions I've been looking for, but OK...

 I'm sorry for the harsh tone, but I just find it hilarious that people who
 explained that proof-of-stake is not going to work because an 

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 to aid the greedy behavior even
 at a potential loss to themselves this strategy becomes a loser even
 for the purely greedy participants. It would be interesting to
 characterize the income tradeoffs for different amounts of altruism,
 or whatever convergence problems an attempt by altruistic
 participaints to punish the forkers might create.

Not only that, greedy miners may actually have an incentive to just
follow the longest chain. Say I'm a small miner and I know that the
chances of re-mining the high tx and getting that block into the
longest chain are minimal or null. Then I will probably prefer to just
mine on top of the longest chain.
So If everyone acts rationally in his own interest, then the best
choice for the remaining miners is to try to mine a competing block at
the same height n including the high-fee transaction, to collect the
fee for themselves is not necessarily true.
p * 50 can be lower than q * 25 if p  2*q. P and q depend on what
everyone is doing, not just you.

In any case, it is interesting to think about this things since mining
subsidies will eventually disappear and then transaction fees will
ALWAYS be higher than subsidies.

--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-08-06 Thread Jorge Timón
Once you ave the jar, you can also build with

./configure --disable-silent-rules --disable-ccache
--with-comparison-tool=/path/to/your/BitcoindComparisonTool.jar

Instead of the regular

./configure

And after that make check will run most of the tests the pull tester does.


On 8/5/14, Mike Hearn m...@plan99.net wrote:
 No problem.

 The pull tester entry point can be found here:

 https://github.com/bitcoinj/bitcoinj/blob/master/core/src/test/java/com/google/bitcoin/core/BitcoindComparisonTool.java

 (nb: in the near future I will be re-namespacing the library from
 com.google.bitcoin to org.bitcoinj to reflect that it no longer has
 anything to do with Google and then this link will break).

 The code itself is a rather bad example of copy/paste coding and I can say
 that, because Matt knows it and already plans to refactor things ;) So if
 anyone is thinking of adding tests 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 with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoin Protocol Specification

2014-07-08 Thread Jorge Timón
There's this (not sure how complete it is):
https://en.bitcoin.it/wiki/Protocol_specification

Also there's a good introduction to technical details here:

https://bitcointalk.org/index.php?topic=375524.0

I hope that is useful.


On 7/8/14, Matt Whitlock b...@mattwhitlock.name wrote:
 Is anyone working on a similar specification document for Satoshi's P2P
 protocol?  I know how blocks and transactions are structured and verified,
 but I'm interested in knowing how they're communicated over the network.

 --
 Open source business process management suite built on Java and Eclipse
 Turn processes into business applications with Bonita BPM Community Edition
 Quickly connect people, data, and systems into organized workflows
 Winner of BOSSIE, CODIE, OW2 and Gartner awards
 http://p.sf.net/sfu/Bonitasoft
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jorge Timón

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-25 Thread Jorge Timón
+1 on setting up the payment protocol extensions process more formally.
On the feature itself, it is interesting to note that some
complementary currencies backed by national currencies offer a
discount when converting from fiat to complementary, which has an
equivalent effect to this discount for paying with btc. The main
difference is that in local currencies the merchants are a relatively
small group and the discount is uniform whereas here each merchant can
set his own discount. There's scientific studies on how different
currency features like these discounts affect adoption, velocity and
other variables. I can ask for them if anyone is interested.

On the implementation, I think a percentage/proportion would be
preferable over an amount in satoshis.
Let's imagine for a second that the bitcoin payment protocol ends up
being a generalized and universal payment protocol. The field would be
really something like discount/additional_charge for paying with the
chosen currency/payment_method.
You could have 0.95 for a 5% discount or 1.05 for a 5% additional
charge. Mhmm, maybe a flat discount/charge in addition to the
proportional one...

On security, being an optional field, I don't see how can it harm anything.
It is true that the merchants can lie about the discount, but wallets
can be smart or stupid about it, or just completely ignore the field
as they wish.

Anyway, it feels like a random simple extension as an excuse to
develop the extension process. If it gets too complicated we can start
with a simpler and less critical one but it's hard for me to imagine
it.


On 6/25/14, Mike Hearn m...@plan99.net wrote:

 I agree. It would be even sillier to start specifying container formats
 for random one-off that would be kind of nice, I guess features.


 No, it'd be sensible.

 Here's a list I drew up a long time ago of features I imagined adding to
 the payment protocol:

 https://bitcointalk.org/index.php?topic=270055.msg2890147#msg2890147

 The protocol is there to contain features! There is zero benefit to
 slavishly following some religious notion of purity or minimalism here. The
 shared resource in question is just varint encoded integers. So, we should
 be guided by what will help our users and what will help adoption.

 Anyway, Gavin asked me to start handling more BIP 70 stuff a few weeks ago.
 I want to use something simple to set up 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

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 implement the wallet feature. I'm not totally convinced
 it should become an SPV wallet given the complexity of doing that. But if
 you did want to separate the wallet code from the full node then that'd be
 the way to do it.

 The question is; what does this buy us, and is it worth the potentially
 huge amount of time it could take? My gut feeling is we have bigger fish to
 fry. There's plenty of work to do just on the core consensus code, making
 Bitcoin Core into a competitive wallet as well would be an additional
 burden.

Exactly, this is part of my point, the qt-wallet does not support SPV
operation at this point, and that complex work should be done after
the wallet is separated. Thus the first version of the separated
wallet should be functionally equivalent to today's wallet, that is, a
full node wallet (even though I understand Wladimir's arguments
against full-node wallets).

 I'm sorry, but I still don't know what Electrum has to do with all this.


 People use Electrum as shorthand to mean something a bit like the P2P
 network, but with trusted remote servers which build additional databases
 and thus support additional commands.

Ok, thanks. So a bitcoin core node which maintains and serves
additional indexes (say, an utxo index via rpc or something else) is
referred to as an electrum even though it doesn't use
electrum-server. Strange, but now I get it.

So in summary:

1) I accept the library approach over the core-wallet protocol.

2) That doesn't necessarily mean that optionally maintaining
additional indexes in the core is not interesting for some use cases
(interesting for bitcoind, I don't care much if electrum-server
currently does this and more [with more dependencies]). Although
Pieter thinks that should also be separated into an index node too,
but I think that's another discussion.

3) The wallet doesn't currently operate as SPV and that work should be
done (if there's enough interest) only after the wallet is separated
from the core.

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 instead of something more
direct when you control both processes?

Wladimir, of course headers-first is generally good, and of course
nobody will be force to separate the code in a way he doesn't like, I
was just testing the waters to see what people had in mind, since I
realized the ideas could be more different than I had assumed.
I don't have any issues with electrum, I'm just not convinced by the
arguments that say that the indexes must be necessarily out of the
core, specially when some of them could be committed in the future.
So I'm all in favor of modularity and competing codebases, I'm just
not convinced that the core full-node must be necessarily restricted
to validation only (for example, I think it should maintain a minimal
and non-optimized mining functionality,even if it's only used for
testing purposes).

So far it is great that everybody seems to agree that the wallet code
needs to be separated.

Thanks everyone for sharing your views on the subject.

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 possible, ideally only
 when you do transactions or want to check for them.

 - A full node should be online 24/7 or it is virtually useless to
 the network.

 I think btcd has done this right.

 A wallet is a daemon that runs constantly in the background, just like
 the full node.

 The GUI (which is distinct from the wallet) runs as little as
 possible. Presumably there's no need for a 1:1 relationship between
 wallets and GUIs.

I think he means that the wallet shouldn't be running as much as it is
currently doing.
But yes, I think you're right about wallets and GUIs not necessarily
mapping 1:1.

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Plans to separate wallet from core

2014-06-23 Thread Jorge Timón
I know there are plans to separate the wallet from the core code and I
think it's a great idea that will result in cleaner and more modular
software.
But it seems like my assumptions on how this would be done may be incorrect.

I was assuming that the wallet would consume data from a trusted
bitcoind core node using rpc or a better interface like an http rest
api (see PR #2844).
So the core would take care of the hard consensus stuff, and the
wallet would maintain its own database with private keys, addresses,
balances, etc. and would consume some data contained in bitcoind's
database.
I also assumed that the interface between wallet and core would
include queries to the UTXO (see PR #4351) and maybe TXO (see PR
#3652) for getting the historic balances.

As said, I'm not sure these assumptions are true anymore so I ask.
Is this the plan?
Is the plan that the wallet will use the p2p directly and maintain its
own chain database?

Well, it's something that generally interests me so if anyone can
detail the steps for separating the wallet a little bit, maybe I can
help with some of the steps.

Maybe there's no roadway yet. In that case I would like to advance
that discussion 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.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 don't collectively lemming us all off a cliff by
 doing that ;)

Replace-by-fee doesn't imply the use of green addresses (there's other
solutions to 0 conf transactions in that context, for example,
scorched earth). And giving up the non-enforceable first-seen
default mining policy doesn't mean giving up on the Bitcoin
experiment either.

--
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.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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.
The following functions (maybe more) could become methods of Policy:

script IsStandard
main IsStandardTx
main AcceptToMemoryPool

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-04-24 Thread Jorge Timón
On 4/23/14, Mike Hearn m...@plan99.net wrote:
 I guess word honest might have different meanings, that can be a source
 of confusing.
 1. Honest -- not trying to destroy bitcoin
 2. Honest -- following rules which are not required by the protocol


 I'm using it in the same sense Satoshi used it. Honest miners work to
 prevent double spends. That's the entire justification for their existence.

I thought the mechanism they used to prevent double-spends was proof of work.
Therefore dishonest miners where only those who mine on top of a block
which is not the longest valid chain they've seen.
To distinguish this definition from your own honest miners are those
who decide on double-spends by mining the transaction they saw first
definition I propose to give another new name to the later, instead of
changing the definition of the former.
So inside the group of honest miners we have some that decide on
transactions based on reception times and others that simply maximize
their revenue while respecting the protocol rules.
I suggest stupid miners and smart miners respectively as more
clear terms for what we're talking about here.

 Miners that are deliberately trying to double spend are worse than useless.

I completely disagree.
Miner's proof of work makes transactions irreversible. Even if zero
confirmation transactions weren't possible in a replace-by-fee
environment, that's very useful.
Even if you always had to wait for transactions to be confirmed with
some irreversible proof of work (as described in Satoshi's
whitepaper), it doesn't follow that automatically resolves the
Bitcoin experiment as a failure. I don't understand how can you
conclude that.

But in fact 0 conf txs are possible *precisely* using replace-by-fee,
as described in the 
0 confirmation txs using replace-by-fee and game theory thread. So
that conclusion is definitely wrong.

On your concrete proposal, it seems to me that you're trying to
prevent double-spending without relying on proof of work, which I
think it impossible in the context of a truly p2p system.
I don't think your current proposal 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/

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-04-24 Thread Jorge Timón
Here is a solution to the problem of having 0 confirmation
transactions that relies on game
theory and most miners implementing replace-by-fee and child-pays-for-parent.

This has been proposed before
http://sourceforge.net/p/bitcoin/mailman/message/30876033/
I'm just going to describe the general idea in more detail.

Here's a small draft on how this could work:

Alice goes to Bob's store and wants to buy something cheaper than a
car, say a smartphone.
So Bob says, it's 200 usd in btc, please pay me 400 usd in btc
So Alice signs a tx with 400 and no fee with her old phone and she
just sends it to Bob rather than the network.
Bob creates a child transaction keeping 200 and giving 199.9 (0.1 usd
fee) back to Alice.

But you know, Alice wants to double spend.
She double spends 399.8 to herself (0.2 fee)
Bob thinks last chance, he double-spends the child: 200 to Bob, back
199 to Alice (1 usd fee).
Alice is stubborn: 398 to Alice (2 usd fee).
Bob is really pissed off, double spends the child: 400 in fees.

So, ok, Bob lost the phone and got nothing but Alice has paid twice as
she needed for the phone.
Nobody's happy thus everybody's happy.

This is similar to the general game theory stag hunt case.
The payoff matrix could be something like this:

Bob returns change   Bob burns in fees
 -++---
  Alice behaves + 1 , + 1- 1, + 1
 -++---
  Alice double-spends   + 3, - 1 - 1, - 1

The game has two Nash equilibria, but cooperation is Pareto efficient.

Replace-by-fee and child-pays-for parent cannot be prohibited by a
protocol rule.
I believe all miners will eventually implement these policies because
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://freico.in/

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 given the possibility that transactions arrived
 at different times.

 I'm continually amazed at how many people seem to see the current algorithm
 as the goal in and of itself, instead of an imperfect but workable means of
 achieving the actual goal.

I'm not saying proof of work is the goal, the goal is still p2p
transaction serialization.
And that's achieved through proof of work, not through miner's honesty.

 This definition of honesty is not my own, the one Bitcoin has always used.

Whatever, let's keep calling stupid miners honest miners, smart
miners dishonest-by-replace-by fee miners and miners that do replace
by fee and also hash on top of old blocks utterly dishonest miners.

 Obviously if Satoshi had wanted transactions to be double spendable by fee
 in the mempool he would have made Bitcoin work that way, instead of coming
 up with the nSequence based replacement scheme instead.

Maybe Satoshi hadn't thought in depth about replace-by-fee when he
wrote the code.
Why should we care?
If nSequence was a design mistake Satoshi did, should we maintain it
to somehow honor him?
Maybe the payment protocol shouldn't have been developed because he
had some weird ideas about paying to ips? Maybe we shouldn't write any
tests because he didn't do so?
This persistent argument from authority is annoying.

 First-seen *is* a protocol rule, as much as Set-Cookie storing data in a
 browser is an HTTP protocol rule. The fact that auditing compliance with it
 is harder to do than some others does not make it less of a rule.

It is not a protocol rule that validators can use to discriminate the
longest valid chain and therefore is not enforceable. Not even through
a softfork because miners can't know which transactions other miners
saw first.
So if it is a protocol rule, I think it shouldn't be.

 Again you are hopelessly confused. Miners that are trying to double spend
 are *by definition* not making transactions irreversible, they are trying
 to make transactions reversible.

Miners that mine on top of the longest valid chain are helping in
making transactions irreversible whether they implement a first-saw or
a replace-by-fee policy.

 Look at it this way. There is no inherent reason BitUndo has to undo only
 Finney attacks. If it gets sufficient hash power it could offer undoing of
 1-confirm transactions too, right? Sure it'll mostly fail but that's
 already a part of its business model. Sometimes it'll get two blocks in a
 row and succeed. It's a very minor tweak to what they're doing. Would you
 argue these miners are still useful? After all, it's impossible to be
 certain after the fact that miners built on top of the wrong block
 because forks occur naturally.

That's not what I'm saying. Miners that don't mine on top of the
longest chain are dishonest by my own definition as well.
You want to equate replace-by-fee dishonesty with
trying-to-rewrite-history dishonesty by saying that the transactions
that have been seen in the network are already history and that's
where we disagree. I think only what's in the chain is history and I
also think that's the whole point of proof of work.
And I also disagree that all the people who think this way are
hopelessly confused. We may be confused, but I think there's always
hope for removing confusions provided that there's will to learn,
which I think it is at least my case.

 What I said is, if you believe all miners are willing to double spend for a
 fee then this resolves the experiment as a failure. This is also obvious -
 if you can pay miners to go back and rewrite the chain at will, Bitcoin
 doesn't work.

This is in fact quite polemic and thus obviously not obvious.
Bitcoin works because rewriting the chain gets exponentially more
expensive as time passes.

 Because all miners follow this ridiculous policy, they should be willing to
 fork the chain at any point to claim the higher fee on the new tx. After
 ...

 Do you see now why your definition of honesty is completely broken?

I see now that I may have not properly expressed myself in the earlier
post since you clearly misunderstood what I meant by smart miners.
By that I mean miners implementing replace-by-fee and
child-pays-for-parent policies Not miners trying to rewrite history,
which I agree is about as smart as mining on top of orphan blocks.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform

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 child-pays-for parent cannot be prohibited by a
 protocol rule.
 I believe all miners will eventually implement these policies because
 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?

 A few things:

 1) Replace-by-fee doesn't protect against sybil attacks; only

No worse than the current situation.

 2) Replace-by-fee scorched earth does require you to keep private keys
 online to sign the replacements. Not a big deal, but it's yet another
 reason why you wouldn't want to use it for high-value stuff.

High-value transactions should wait for several confirmations.

 3) It doesn't directly solve finney attacks(1) where the miner mines the
 transaction in private. However finney attacks are only relevant if
 there is high centralization of hashing power, and all other proposed
 mechanisms, e.g. coinbase reallocation, themselves do a lot of harm to
 decentralization. (just look at how coinbase reallocation lets large
 pools bully smaller miners out of business by blacklisting their blocks)

Again, no worse than the current situation. And regular double-spends
attacks are much simpler than finney attacks.

 One interesting thing with regard to finney attacks and replace-by-fee
 though is that enforcing hasher visibility of the blocks they are mining
 - what getblocktemplate was meant to do voluntarily - lets any hasher
 detect a finney attack double-spend and broadcast it. They have a weak
 incentive to do so - the scorched earth reply is a high-fee transaction
 of course and pre-broadcasting transactions makes blocks propagate
 faster - at which point you're back to a public double-spend.  Enforcing
 visibility of block contents to hashers is definitely a good thing for
 decentralization.

Where can I read more about enforcing hashing visibility of block contents?
Sounds somewhat similar to p2pool to me but I'm not sure I understand it.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 proof of work, to different ends.

Yes, you can disentangle replace-by-fee policies from rewriting
history attacks.
That's exactly what I'm saying.
Proof of work is the most important thing that makes the blockchain
hard to tamper with.

 Whatever, let's keep calling stupid miners honest miners


 No, let's not. Your definition of smart miner is one I'd called stupid
 miner (or possibly short bitcoin miner). They are miners who would
 reduce the value of their coins, by making their own system less useful.
 That's not smart, that's simply short termism taken to an extreme, sort of
 like a business owner who puts so much pressure on his employees they all
 quit. He might have gained a bit more profit in the short term, but only at
 the cost of destroying his business that would have given lower but
 sustainable returns over the long term.

Whatever, pick the terms yourself but let's just stick to the same ones, please.
I've read this argument before, but I simply don't buy it because I
disagree with the premise that replace-by-fee reduces the value of the
coins (not to mention we shouldn't assume miners stock coins for
long).
I think replace-by-fee policies are actually an improvement over
first-saw-first-included policies.

 This persistent argument from authority is annoying.


 Peter always says this too, but it's again an incorrect position. This is
 not an argument from authority.

I don't know about other occasions with other people but what you just
used with me was an argument from authority fallacy. Now you're using
a false analogy to try to convince us you didn't.

If I was saying we should change the maximum from 21 M to 100 M
because mining subsidies could continue for longer.
Mining subsidies aren't necessarily a good thing or
That's no justification for a hardfork or
That could destroy people's confidence in the currency
would be logical arguments.

No, because Satoshi picked 21 M would be an argument from authority fallacy.

 That's not what I'm saying. Miners that don't mine on top of the
 longest chain are dishonest by my own definition as well.


 Right, but I don't accept this definition of honesty. That's not a
 definition any man on the street would use:

Whatever let's use whatever definitions you want, if I don't like your
definition of honesty I will just invent a new term to define my own.

 If you pay for something with forged bank notes and walk out
 immediately, you are honest. But if you pay for something with forged bank
 notes and hang around for longer than 10 minutes, you are dishonest

Sorry, I don't see the analogy.

 That would sound silly to anyone because what's so special about 10
 minutes? It's the act of passing counterfeit money and stealing from the
 merchant that's the dishonest act, how long it takes is irrelevant.

10 minutes is what Satoshi picked. Just kidding...

 In Bitcoin, the dishonest act by the user is signing for the same output
 twice (ignoring special protocols here), and the dishonest act by the miner
 is deviating from normal behaviour for a fee to try and trick the recipient
 into believing they have been paid. The exact details are something
 computer scientists care about, but the average Bitcoin user would not.

People need to understand that Bitcoin transactions are not instant.
For instants transactions you need to rely somehow on trust, use some
trust-less offchain mechanism or use a payment protocol that would
make double-spending irrational (like the one described in the other
thread that uses replace-by-fee).
So I think miner's default behavior should be replace-by-fee. But that
doesn't imply that I want miners to rewrite pow-validated history.

--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Economics of information propagation

2014-04-21 Thread Jorge Timón
I'm not convinced that headers first will result in miners hashing on
top of the block with more work without knowing if it's valid yet
instead of just keep hashing on top of the longest known-to-be-valid
chain.
Both options are risky for the miner in some way, and I guess the
probability of someone hashing an invalid block above difficulty is
too low to be the main concern, but there's intermediate solutions,
like say, waiting to validate at least 5% of the block.

But I don't see how miners mining headers first would result in empty
blocks either.
Why wouldn't them validate and include transactions after they have
received the full block?
They will likely know most of the transaction before receiving the block anyway.
In a future where they ONLY live on transaction fees, why would they
refuse to validate and include transactions? What are they hashing for
then?
If anything, looks like a threat to the current situation with huge
mining subsidies coming from the seigniorage, not a problem that you
would have when the the seigniorage is gone.

In any case, it is true that this is mining policy and therefore out
of the realm of what the protocol can regulate, so we should assume
miners will do whatever it's best for them.

The trade-off between tps and centralization remains: if you want
higher tx volume, less full nodes will be able to process it.

On 4/21/14, Tier Nolan tier.no...@gmail.com wrote:
 On Mon, Apr 21, 2014 at 5:06 AM, Peter Todd p...@petertodd.org wrote:

 Of course, in reality smaller miners can just mine on top of block
 headers
 and include no transactions and do no validation, but that is extremely
 harmful to the security of Bitcoin.


 I don't think it reduces security much.  It is extremely unlikely that
 someone would publish an invalid block, since they would waste their POW.

 Presuming that new headers are correct is reasonable, as long as you check
 the full block within a few minutes of receiving the header.

 If anything, it increases security, since less hashing power is wasted
 while the full block is broadcast.

 Block propagation could take the form

 - broadcast new header
 - all miners switch to mining empty blocks
 - broadcast new block
 - miners update to a block with transactions

 If the block doesn't arrive within a timeout, then the miner could switch
 back to the old block.

 This would mean that a few percent of empty blocks end up in the
 blockchain, but that doesn't do any harm.

 It is only harmful, if it is used as a DOS attack on the network.

 The empty blocks will only occur when 2 blocks are found in quick
 succession, so it doesn't have much affect on average time until 1
 confirm.  Empty blocks 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 Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Timed testing

2014-04-17 Thread Jorge Timón
I'm implementing a new testing mode that produces blocks
periodically. You can get what I have so far here:

https://github.com/jtimon/bitcoin/tree/timed

It depends on pull request #3824 with some improvements on
CChainParams, but after that the changes required to add this new
mode are very small:

https://github.com/jtimon/bitcoin/commit/445321928a143cb9a6f56777cbb7479dd32c3bcd

I guess I need a new genesis block, different magic numbers, etc. So
this is definitely not ready.
You can run it like this:

bitcoind -timedtest -gen=1 blocktime=2000

blocktime defaults to 1000 milliseconds for timedtest mode and 0 for
the rest of the modes.

What could this testing mode be useful for?

Basically, simulations.
For example, you could run several nodes implementing different mining
policies. Let's say I want to mine 50% of the blocks with standard policy,
25% with policy A and 25% with policy B. I can run 1 one for each of
one with block times 2000, 1000 and 1000 respectively.

Maybe I want to detect performance bottlenecks by stressing this mode
with as many transaction as can be processed, maybe removing the
block size limits in the simulations.

But this still doesn't serve for hardfork or double-spend attacks
simulations without calculating any pow, which would be another
interesting feature for a new testing mode.
I would like to implement the new mode following as the concept of
private chains described in freimarkets:

http://freico.in/docs/freimarkets.pdf
https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#private-ledgers
https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#off-chain-transactions

I know this could be considered a non-bitcoinish application and
therefore be controversial as discussed in PR 3824, so I want to keep
the conversation focused on testing use cases useful to bitcoin itself
only: additional changes can be implemented elsewhere.
One way I think you could support chain races simulations by using a
private mode could be the following:

1) The private mode works like the timed mode in how often it
   produces blocks.

2) In private mode you replace the pow-related fields with a
   blockPubkeyScript and a lastBlockSigScript fields. In the genesis
   block, lastBlockSigScript is empty and the initial
   blockPubkeyScript can be an optional parameter like blocktime. You
   can set any valid script, probably p2sh, maybe with multisig to
   allow different nodes to sign.

3) In this context, longer chains mean more work. Another way to
   see it is that all blocks just contain work==1 in them.

So let's say we want to simulate an attack using 50% standard and 50%
attacker blocks. You set up the private mode script to be a 1 of 2
multisig and make each node sign always with the same private key
(maybe an additional parameter).
You make the attacker reject any blocks from height X that he hasn't
signed himself to get the result you wanted: the standard node will
produce blocks on top of the longest chain while the attacker will
only hash on top of his own blocks.

So my question to the community is, how invasive is this to bitcoin's
source code?
In my opinion, done properly could actually result (apart from getting
the new features) in more readable code, not less, since you will
probably need to make sure proof of work functionality is properly
encapsulated during the implementation process (see PR 3839 for a first
step on that direction).
But, should I push a private mode to the core or just the timed one
and implement the private mode elsewhere?

Of course other 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 new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 the chain. It's been done many times.

Yes, thank you. I guess that's what everybody is doing to measure
validation performance.
So I guess the timedtest mode doesn't make much sense, at most only as
the blocktime parameter defaulting to zero. If bool
MineBlocksOnDemand() gets refactored out of ChainParams into a
parameter (maybe just use genproclimit ?), you can have the periodic
block generation and the generation on demand reusing the same regtest
mode.

So it seems a new mode only makes sense if the -private mode makes
sense, which in turn only makes sense to include in bitcoind if it's
useful enough for the network attack simulations, which remains the
open question.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Timed testing

2014-04-17 Thread Jorge Timón
Thank you for all the explanations on how to use regtest to reproduce
the example scenarios.
It seems like a private mode wouldn't be particularly helpful for
testing so I won't create a pull request and will just work on the
private chains separately from bitcoind.

Going back to chainparam modes in general, I've heard Sipa complain
some times about regtest being too specific, arguing that some of the
behaviors should be specified as independent parameters instead of
chainparams attributes.
One example could be bool CChainPrams::MineBlocksOnDemand() (see
https://github.com/jtimon/bitcoin/commit/5bd4bc7f3694e46568c9276f0cb26402dfb99718
).
If that was an independent parameter that people set to true when
using regtest, the blocktime param I was proposing for -timedtest
could also be implemented as an independent parameter without any need
for a new mode.

It's not clear to me if the timedtest parameter would be useful for
bitcoind testing or not, but it's just something I've noticed while
playing with this part of the code.
Sipa, is this the kind of thing you refer to when you say regtest is
too specific?
Do you have any suggestion on how to solve the issue as part of PR 3824?

Well, any suggestions from anyone on how to improve PR 3824 are
welcomed, I was just asking specifically to sipa because as said it is
my understanding that he had some complaints about regtest and I think
this is something simple enough for me to start contributing to
bitcoind. Specially given that I 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 guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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.

This doesn't make much sense to me.
If you print shares on gold plates instead of paper, is that gold
part of the capital of the company? I don't think so.

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees_APR
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 not assets for the company when someone else
holds them.
What you're doing is getting less capital for the company due to the
money that is going to pay the gold costs.
Are you rising capital or selling gold?
It doesn't make sense to do both at once.
You need money, why would you spend money on gold before asking for
other people's money to build your company?
Investors will appreciate the convenience of being able to buy shares
of your company and gold separately (or not buy gold at all).

It may even be more clear for other use cases different than stocks.
Does an IOU written in a gold plate make sense to you?

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-04-05 Thread Jorge Timón
I like both DD-MM- and -MM-DD. I just dislike MM-DD- and -DD-MM.

On 4/4/14, Jeff Garzik jgar...@bitpay.com wrote:
 On Fri, Apr 4, 2014 at 3:01 AM, Wladimir laa...@gmail.com wrote:
 Personally I'd prefer to standardize on ISO 8601 (-MM-DD) dates as
 well.

 +1 for all-numeric, easily computer parse-able without a lookup table,
 and naturally sorts correctly in a lexicographic sort.

 English (or any language) should never be in a date format, on a computer.

 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/

 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jorge Timón

http://freico.in/

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 that is unambiguous across all cultures is -MM-DD. (No culture
 uses -DD-MM, or at least the ISO seems to think so.)

Probably my acceptance of DD-MM- is caused by cultural bias.
The ISO -MM-DD seems what you normally do with indo-arabic
numerals: put the more weighted numbers on the left, so I guess it's
the most universal (in addition to being standard).

-- 
Jorge Timón

http://freico.in/

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-04-01 Thread Jorge Timón
On 4/1/14, Matt Corallo bitcoin-l...@bluematt.me wrote:
 Also, should we really do this with a soft fork when we can take this
 opportunity to redesign the whole system with a hard fork? This is out
 chance to switch to a whole new script engine!

+1
The hard fork also forces the whole community and not a few miners to decide.
Well, if it is possible for the community to reach an agreement with
such a short time frame...

 Matt

 On April 1, 2014 3:00:07 PM EDT, Pieter Wuille pieter.wui...@gmail.com
 wrote:
Hi all,

I understand this is a controversial proposal, but bear with me please.

I believe we cannot accept the current subsidy schedule anymore, so I
wrote a small draft BIP with a proposal to turn Bitcoin into a
limited-supply currency. Dogecoin has already shown how easy such
changes are, so I consider this a worthwhile idea to be explored.

The text can be found here: https://gist.github.com/sipa/9920696

Please comment!

Thanks,

--
Pieter

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jorge Timón

http://freico.in/

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 could merged
mine with other leafs in other independent trees.
Anyway, I'll better comment on the 2 way peg and merged mining issues
raised so far.

On 3/25/14, Gregory Maxwell gmaxw...@gmail.com wrote:
 On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach m...@monetize.io wrote:
 More importantly, to your last point there is absolutely no way this
 scheme can lead to inflation. The worst that could happen is theft of
 coins willingly put into the pegging pool. But in no way is it possible
 to inflate the coin supply.

 I don't think it would be entirely unfair to describe one of the
 possible ways a secondary coin becoming unbacked can play out as
 inflation-- after all, people have described altcoins as inflation. In
 the worst case its no _worse_ inflation, I think, than an altcoin is--
 however.

I think that's an obscure corner case that is not likely going to ever
be implemented.
If you produce real inflation there will likely be a bank run.
If you're going to implement something equivalent to demurrage you
should call it demurrage instead of inflation.
And that's only for the pegged coin in the side chain: BITCOINS IN THE
MAIN CHAIN WILL NEVER BE INFLATED USING 2P2.

So I think it's less confusing if we just say that 2-way peg can't
produce inflation in general, and leave unless you explicitly
introduce an inflation mechanism as a probably unnecessary
clarification.

 I see your point, but gmaxwell accurately guesses below that when I'm
 talking about inflation, I'm including the inflation of the alt too.

You don't need inflation on the side chain. You don't need to create
another currency to create another chain with different and maybe
experimental features, that's the whole point.

With merged mining, you're adding up the different created seigniorage
subsidies to the same fire to share the heat.
With 2-way peg, you don't even need to create a new p2p currency with
a seigniorage to burn on hashes or be accused of pre-mining as the
more ecological alternative in existence.
Your chain can secure itself on fees, just like bitcoin in the future.
Merged mining will help, but it's not the panacea and you will need to
reward miners because that's what your security ultimately depends on.
This is mostly about not burning the world, it may not be as
interesting to you as improving bitcoin's scalability but you're not
doing anyone a favor by presenting both concepts as being
incompatible, not even yourself.

 With tree-chains that's particularly obvious as the scheme doesn't try
 to privilege one chain over another beyond parent-child relationships.

If I understand it correctly, all the utxo nodes in the tree implement
the same rules so doesn't seem suitable to solve the same problems.
I understand that merged mining IS NOT a solution to scalability on
its own, having 10 independent 1MB blocks is no worse than 1 10MB
block in terms of performance vs centralization.
But maybe it's possible to have a 10 GB sharded side-chain (your
proposal) that it's merged mined with the main chain and where the
currency of the side-chain comes from.
So merged mining could help solve the scalability problem indirectly.
And 2-way peg could be a useful previous step for your proposal to be
deployed on production, with real bitcoins without forcing all
bitcoin users to take the associated risks, only the people who opt
in.

 Incidentally, I understand that the pegged chains are meant to be
 merge-mined.

2 way peg doesn't require merged mining but it is assumed that merged
mining will be used since it provides more security than independent
mining.
I thought you agreed with this and your claim was just that merged
mining is less secure than embedded consensus, something I have
never denied, my complain against embedded consensus is that it
doesn't seem to scale (with Bitcoin as it is today) and can't offer
many features that a hardfork merged mined chain could offer (like
those explained on our freimarkets proposal).
But since you're implying again that merged mining is superior to
independent mining is generally false, I invite you again to
dismantle my example

http://sourceforge.net/p/bitcoin/mailman/message/31806950/

or to prove your hypothesis that is free to attack merged mining
chains by attacking namecoin for free. Either one will serve, my
you're not responding to any of the suggestions.
Instead, you're saying that people defending merged mining assume
that attackers are economically rational. I think you're referring to
me and it's false.
Of course the attacker doesn't need to be economically rational. For
some unknown reason he's attacking a chain, without questioning the
rationality of the attack, I just sum costs, 

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

2014-03-22 Thread Jorge Timón
On 3/22/14, Peter Todd p...@petertodd.org wrote:
 There's been a lot of recent hoopla over proof-of-publication, with the
 OP_RETURN data length getting reduced to a rather useless 40 bytes at
 the last minute prior to the 0.9 release.


I'm not against about miners accepting transactions that have longer
data  in non-utxo polluting OP_RETURN than whatever is specified as
standard by the reference implementation, maybe it should be risen in
standard but I think it was assumed that the most common case would be
to include the root hash of some merklized structure.
My only argument against non-validated proof of publication is that in
the long run it will be very expensive since they will have to compete
with transactions that actually use the utxo, a feature that is more
valuable. But that's mostly speculation and doesn't imply the need for
any action against it. I would strongly opposed to against a
limitation on OP_RETURN at the protocol level (other than the block
size limit itself, that is) and wouldn't mind if they're removed from
isStandard. I didn't payed much attention to that and honestly I don't
care enough.
Maybe this encourages miners to adopt their own policies, which could
be good for things like replace-by-fee, the rational policy for
miners, which I strongly support (combined with game theory can
provide instant transactions as you pointed out in another thread).

Maybe the right approach to keep improving modularity and implement
different and configurable mining policies.

 All these methods have some overhead compared to just using OP_RETURN
 and thus cost more.

I thought the consensus was that op_return was the right way to put
non-validated data in the chain, but limiting it in standard policies
doesn't seem consistent with that.

 Finally I'll be writing something more detailed soon about why
 proof-of-publication is essential and miners would be smart to support
 it. But the tl;dr: of it is if you need proof-of-publication for what
 your system does you're much more secure if you're embedded within
 Bitcoin rather than alongside of it. There's a lot of very bad advise
 getting thrown around lately for things like Mastercoin, Counterparty,
 and for that matter, Colored Coins, to use a separate PoW blockchain or
 a merge-mined one. The fact is if you go with pure PoW, you risk getting
 attacked while your still growing, and if you go for merge-mined PoW,
 the attacker can do so for free. We've got a real-world example of the
 former with Twister, among many others, usually resulting in a switch to
 a centralized checkpointing scheme. For the latter we have Coiledcoin,
 an alt that made the mistake of using SHA256 merge-mining and got killed
 off early at birth with a zero-cost 51% attack. There is of course a
 censorship risk to going the embedded route, but at least we know that
 for the forseeable future doing so will require explicit blacklists,
 something most people here are against.

The proof of publication vs separate chain discussion is orthogonal
to the merged mining vs independent chain one.
If I remember correctly, last time you admitted after my example that
merged mining was comparatively better than a separate chain, that it
was economically harder to attack. I guess ecological arguments won't
help here, but you're confusing people developing independent chains
and thus pushing them to a less secure (apart from more wasteful
setup) system design.
Coiledcoin just proofs that merged mining may not be the best way to
bootstrap a currency, but you can also start separated and then switch
to merged mining once you have sufficient independent support.
As far as I can tell twister doesn't have a realistic reward mechanism
for miners so the incentives are broken before considering merged
mining.
Proof of work is irreversible and it's a good thing to share it.
Thanks Satoshi for proposing this great idea of merged mining and
thanks vinced for a first implementation with a data structure that
can be improved.

Peter Todd, I don't think you're being responsible or wise saying
nonsense like merged mined chains can be attacked for free and I
suggest that you prove your claims by attacking namecoin 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/

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https

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

2014-03-16 Thread Jorge Timón
Some comments.

On 3/16/14, Adam Back a...@cypherspace.org wrote:
 6. a fraud proof is an SPV proof with a longer chain showing that the proof
 of burn was orphaned.

As discussed, reorg proof it's a more appropriate term since the
reorg can happen without any fraud. It also prevents the term from
being confused with the fraud proof that auditors (full nodes that
can't create blocks) produce for private chains.

 Apart from pegging from bitcoin to a side-chain, if a private chain is made
 with same rules to the side-chain it becomes possible with some
 modifications to the above algorithm to peg the side-chain to a private
 chain.  Private chain meaning a chain with the same format but signature of
 single server in place of hashing, and timestamping of the block signatures
 in the mined side chain.  And then reactive security on top of that by full
 nodes/auditors trying to find fraud proofs (rewrites of history relative to
 side-chain mined time-stamp or approved double-spends).  The reaction is to
 publish a fraud proof and move coins back to the side chain, and then
 regroup on a new server.  (Open transactions has this audit + reactive
 model
 but as far as I know does it via escrow, eg the voting pools for k of n
 escrow of the assets on the private server.) I also proposed the same
 reactive audit model but for auditable namespaces [4].

 Private chains add some possiblity for higher scaling, while retaining
 bitcoin security properties.  (You need to add the ability for a user to
 unilaterally move his coins to the side-chain they came from in event the
 chain server refuses to process transactions involving them.  This appears
 to be possible if you have compatible formats on the private chain and
 side-chain).

In this case you can't require a side chain proof of burn to move back
to the side chain or the funds could be locked by the dishonest
private chain operator (accountant in freimarkets[1] terminology). By
allowing unilateral withdrawals, you impose on the private chain the
task of observing the side chain looking for double-spends, censoring
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/

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

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,
 and then plan on rolling back to mBTC when the price crashes from altcoin
 money supply inflation competition.

No, even if bitcoin crashes to 1 usd you don't need to change back to
BTC, you can keep the existing-accounting-tools friendly micro. That's
the whole point, having one true only unit change. You would only
need to change it if there was a sub-satoshi hardfork, which doesn't
seem necessary anytime soon.

On 3/13/14, Mike Hearn m...@plan99.net wrote:
 I think it is highly optimistic to assume we'll need another 1000x shift
 any time soon. By now Bitcoin isn't obscure anymore. Lots of people have
 heard about it. Getting from $1 to $1000 was amazing, but it was possible
 through huge media coverage. Getting from $1000 to $1,000,000 would take
 massive adoption of the kind Bitcoin isn't ready for yet.

We shouldn't make any assumptions about the future price of bitcoin to
make the decision.

On 3/13/14, Mike Hearn m...@plan99.net wrote:

 Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying
 than 3123.45 uBTC.


 This is subjective though. To me the first price looks like the price of a
 cup of coffee (or I just mentally double it). The second looks like the
 price of an expensive holiday.

This sounds very US-centric to me. Aren't you thinking in usd?

It won't look like an expensive holiday to, say, someone used to Viet
Nam Dong (VND), Uzbekistani Som (UZS) or Mongolian Tugrik (MNT).

http://coinmill.com/BTC_calculator.html#BTC= 0.00312345


People seem to like mBTC is just an ad populum fallacy: millions of
flies can actually be wrong. Also you haven't showed them micros,
maybe they like it too.

So the only valid argument I've heard in favor of mBTC so far is some
wallets/services are doing it wrong already.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

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 assumption about the future price?

You can just remove my assertion about the likeliness of the need of
sub-satoshis and the main claim still stands.

 The currencies I'm familiar with are CHF, USD, EUR and GBP, which all have
 roughly similar values. I guess such currencies make up the bulk of the
 Bitcoin userbase at the moment.

Fair enough, not US-centric but western-centric then.
In any case the 3000 micros will look like expensive claim is still
very relative.

 People seem to like mBTC is just an ad populum fallacy: millions of
 flies can actually be wrong. Also you haven't showed them micros,
 maybe they like it too.


 Saying it's already popular and would take work to change is not really a
 fallacy now, is it?

No, it's not. That's what I said the current adoption by some wallets
and services was the only valid argument immediately after dismantling
the actual fallacy.
Did you missed that last sentence or are you intentionally using a
straw man argument?

In summary, yes, that's point is valid, I'm not saying it isn't. I
just wanted to keep us away from the rest argument but pointing out
they are not logic.
I repeat, that's the ONLY valid argument I've heard so far.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-03-02 Thread Jorge Timón
::soul
   grid.coop
  
 Never pick a fight with someone who buys ink by the barrel,
nor try buy a hacker who makes money by the megahash
  
  
  
   --
   Flow-based real-time traffic analytics software. Cisco certified
   tool.
   Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow
   Analyzer
   Customize your own dashboards, set traffic alerts and generate
   reports.
   Network behavioral analysis  security monitoring. All-in-one tool.
  
   http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
   ___
   Bitcoin-development mailing list
   Bitcoin-development@lists.sourceforge.net
   https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 
 
 
  --
  Jeff Garzik
  Bitcoin core developer and open source evangelist
  BitPay, Inc.  https://bitpay.com/
 
 
  --
  Flow-based real-time traffic analytics software. Cisco certified tool.
  Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
  Customize your own dashboards, set traffic alerts and generate
  reports.
  Network behavioral analysis  security monitoring. All-in-one tool.
 
  http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Jeff Garzik
 Bitcoin core developer and open source evangelist
 BitPay, Inc.  https://bitpay.com/

 --
 
 Troy Benjegerdes 'da hozer'
 ho...@hozed.org
 7 elements  earth::water::air::fire::mind::spirit::soul
 grid.coop

   Never pick a fight with someone who buys ink by the barrel,
  nor try buy a hacker who makes money by the megahash


 --
 Flow-based real-time traffic analytics software. Cisco certified tool.
 Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
 Customize your own dashboards, set traffic alerts and generate reports.
 Network behavioral analysis  security monitoring. All-in-one tool.
 http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jorge Timón

http://freico.in/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-02-28 Thread Jorge Timón
On 2/28/14, Peter Todd p...@petertodd.org wrote:
 As usual, you don't need a hardfork.

 Anyway, one-sided trade is sufficient to get a functioning marketplace
 up and running and test out the many other issues with this stuff prior
 to forking anything.

I'm totally FOR experimenting with this as it is and I'm happy that
Alex/Killerstorm is working on regular colored coins.

 You can make the same argument against Bitcoin itself you know...

 A Bitmessage-like network would be trivial to front-run via a sybil
 attack. It's the fundemental problem with marketplaces - the data
 they're trying to publish has to be public.

I don't see the Bitcoin analogy...
Anyway, I still don't think the seller cares, if he sells at the price
he was asking, what would he care about front running those parallel
networks.
I've seen many street markets without public information and they
work just well.

 I don't think this will be a tragedy, because like we discussed on
 IRC, I don't think the primary goal of markets is price discovery, but
 trade itself.

 About historic data, the actual trades are always public, and some
 kind of archivers could collect and maintain old orders for historic
 bid and asks, etc.

 And again, how do you know that record is honest? Fact is without
 proof-of-publication you just don't.

Well, the trades that appeared in the chain actually occurred.
Buying to yourself at fake prices? Be careful, the miner could just
separate the order and fill it himself. Or anyone paying a higher fee,
for that matter.
Again, you haven't addressed why the seller cares more about accurate
historic market data than just his own fees and sell.

 You mean a reverse nLockTime that makes a transaction invalid after a
 certain amount of time - that's dangerous in a reorg unfortunately as it
 can make transactions permenantly invalid.

Yes, I'm aware this is a concern for many people and that's why I
bring it up when there's an useful use case (we have several important
uses in freimarkets).
Probably this belongs to another thread or just #wizards, but if I
remember correctly, the last discussion we had about this, I think
with you and gmaxwell, was more or less like this:

-Valid transactions could get invalid with a regorg
-Just like with any transaction if a double-spend appears, this just
means that you would need to wait for expiry transactions to be
somewhat buried to accept payments from it.
-That introduces fungibility problems.
-True, but doesn't seem a particularly difficult problem (I think we
actually drafted some potential solutions, like introducing a maturity
rule for expiry transactions) and the advantages outweigh that
potential problem IMO.

So 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/

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-02-27 Thread Jorge Timón
First of all, sorry for the delayed answer.

On 2/10/14, Peter Todd p...@petertodd.org wrote:
 Got this:
[...]
Thank you, I knew this wasn't new for us but I doubted we had written
it anywhere.
As said in those mails, being only able to offer AAA for BTC and not
BTC for AAA nor AAA for BBB is enough of a limitation to justify a
hardfork IMO.

On 2/17/14, Troy Benjegerdes ho...@hozed.org wrote:
 Is there a simple way to do cross-chain trades that doesn't need a third
 chain to somehow facilitate things?

These are the two methods I know for cross-chain trading (no third
chain needed in any of them):

https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains
https://bitcointalk.org/index.php?topic=321228

On 2/14/14, Peter Todd p...@petertodd.org wrote:
 You're assuming the seller cares about fairness - why should they? They
 offered a price for an asset and someone bought it; exactly which buyer
 willing to buy at that price was able to complete the trade is
 irrelevant to them. What they do care about is being sure that at
 whatever given price they offered 100% of the buyers willing to buy at
 that price actually see the offer in a reasonable amount of time - at
 the best price the seller will get there will be only a single buyer
 after all so you need that solid proof that said buyer was actually able
 to get the offer.

In fact, I don't think the seller will care enough about this to pay
the proof of publication fee either. Assuming sellers can either
broadcast the order on a bitmessage-like network or use your proof of
publication scheme, the later will be always be more expensive. So my
prediction is that most people will just use the simplest, fastest and
cheapest method, but I guess only time can tell.
I don't think this will be a tragedy, because like we discussed on
IRC, I don't think the primary goal of markets is price discovery, but
trade itself.

About historic data, the actual trades are always public, and some
kind of archivers could collect and maintain old orders for historic
bid and asks, etc.

As an aside, nLockTime would be nice 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, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-02-15 Thread Jorge Timón
Not a lawyer, but I don't see what would prevent me from writing contracts like:

I owe the holder of this contract 10 usd (IOU)

I owe the holder of this contract 10 usd in beer (voucher)

I owe the holder of this p2p asset 10 usd in beer (p2p voucher)

Of course, there must be a legal contract outside of the chain for
this contracts to be enforceable.
Some p2p assets will have them and other's won't. Say Alice pays the
dinner (20 usd) and her friend Bob pays her half of the price in p2p
usd not legally enforceable IOUs issued by him (10 bob:USD).
That's not legally enforceable, so what?
If Bob doesn't pay back Alice would lose 10 usd and would not accept
bob's IOUs anymore, much like it would had happen with a verbal IOU.
The difference is that Alice can sell those bob:USD to other people
who trust Bob.

Different p2p assets have different legal needs.

In any case, I think Peter summarized it very well:

[...]no amount of code can, **by itself**, make data
represent a physical or legal entity. Only consensus and/or authorities
in the real world can do that.


On 2/9/14, Troy Benjegerdes ho...@hozed.org wrote:
  The only 'assertion' of central authority here is people who download
  and
  run the code and submit to whatever the code asserts they are supposed
  to do.
 
  At least with the 'central authority' of the big-business bitcoin
  developer
  cabal I can read the code before I submit to it's central authority,
  and
  this is a significant improvement over amgibuous legislation or
  proprietary
  high-frequency trading algorithms.

 Standard Disclaimer: Digital asset transfer systems are fundementally
 fancy accounting systems; no amount of code can, by itself, make data
 represent a physical or legal entity. Only consensus and/or authorities
 in the real world can do that. Crypto-currencies are only a partial
 exception to that rule, and only because a scarce asset that can be
 transferred digitally appears to have potential to be broadly useful.

 How do I document in the embedded consensus system what the ruling in
 a small-claims court about the ownership of a contested asset was?

 Good accounting systems (such as mercurial, and proper double-entry
 financial accounting tools) allow reverting a bad commit, or bad data
 entry, while maintaining records of the history. Not as good accounting
 systems (like git) allow you to re-write history. What's the equivalent
 user interface, process, and wire protocol for reversing a fraudulent
 transaction while maintaining a full audit trail?

 Courts can't legislate our code, and we can't expect them to download
 and trust our 'distributed de-centralized' digital asset tracking system
 that will be downloaded from a single centralized developer website
 unless we meet them at least halfway, and probably need to propose model
 municipal and county ordinances that go along with our code releases.

 Those considering investing in or otherwise devoting resources to the
 creation of digital asset transfer systems should be warned that their
 value in general remains unproven and losing some or all of your
 investment is very possible, even probable. I myself have doubts that
 these systems serve real-world business needs, but the only way to find
 out is to build them and see.

 I would agree 100% that we need to build them, test the code, use them,
 and then *try them in court*, and make sure we can explain in very simple
 plain language what an 'embedded consensus system' is to the distributed
 de-centralized local court systems.

 --
 Managing the Performance of Cloud-Based Applications
 Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
 Read the Whitepaper.
 http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jorge Timón

http://freico.in/

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-01-22 Thread Jorge Timón
 Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jorge Timón

http://freico.in/

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 if I were to
 create a competitor to Namecoin, perhaps because I thought the existing
 allocation of names was unfair, and/or I had technical improvements like
 SPV, it's easy to imagine Namecoin miners deciding to attack my
 competitor to preserve the value of their namecoins and domain names
 registered in Namecoin.

Namecoin, Devcoin and Ixcoin are also currencies and therefore compete
with Bitcoin.
How is that even Ixcoin (clearly a scamcoin that indirectly damages
the image of Bitcoin) has survived?

My explanation is that miners aren't necessarily holders. It's certain
that there's holders who don't mind and can't do anything about it.
In fact, I think many miners sell their mined coins for fiat to cover
their investment and costs. The profit margin is reduced as the mining
market becomes more competitive, so even for miners it will get very
expensive and risky to do stupid things.
Talking about stupid things, I don't see many bitcoiners throwing
rocks at local currency users or barter clubs nor burning down banks
to protect their investment. Barter is just another competitor in
the media of exchange market.

 The problem here is that my new system has a substantial *negative*
 value to those existing Namecoin holders - if it catches on the value of
 their Namecoin investment in the form of coins and domain names may go
 down. Thus for them doing nothing has a negative return, attacking my
 coin has a positive return minus costs, and with merge-mining the costs
 are zero.

What percentage of Bitcoin/Namecoin miners do you think own namecoins?
How much can they afford to lose to attack competition?

 Without merge mining if the value to the participants in the new system
 is greater than the harm done to the participants in the old system the
 total work on the new system's chain will still be positive and it has a
 chance of surviving.

No, the harm to the old system participants is distributed among all
the participants, not only miners (assuming miners have any
speculative position at all).
I'm not denying that people do crazy and stupid things, but let's at
least allow the anti-competition attacker be equally crazy in both
cases.
Miners attacking competition for one or more of the chains they mine
are acting irrationally in both cases.
You're trying to rationalize the actions of the MM attackers, but
they're just being stupid, since if they weren't, they would just try
to maximize profits.

 Of course, this is what Luke-Jr was getting at when he was talking about
 scam-coins and merge mining: if you're alt-currency is a currency, and
 it catches on, then it dilutes the value of your existing coins and
 people who own those coins have an incentive to attack the competitor.
 That's why merge-mined alt-coins that are currencies get often get
 attacked very quickly.

I have many other explanations for the few currencies that died with
MM (can you remember any name?). At the beginning all altcoins were
much smaller and easier to attack, all of them. Bitcoin mining pools
didn't wanted to update to merged mining and didn't acted very
rationally about it.
Namecoin went through a really delicate situation just before
hardforking to MM, but now is by far the most secure altcoin of them
all, all thanks to MM.
All rational bitcoin miners should also mine namecoin. Period. All
those who consider it competition with their current Bitcoin
speculative position, should just attack in the market by selling
the namecoins as soon as they get them.
Providing security for a chain DOES NOT give it an utility or rise its demand.
Operation COSTS DO NOT CAUSE VALUE.

About Luke-Jr's thinking, I don't think it's along those lines.

If you create a new chain for the long term, you should try to
maximize its security and that currently means you should merged mine
with bitcoin.
The main rational reason to never do merged mining is to prevent
competitive and rational miners from crashing the price of your
currency, which is everything a scamcoiner cares about, the price and
market cap.

Of course Luke-Jr can correct me if that's not how he thinks.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 make sure the Twister blockchain
 gets killed at birth.

You don't have to MM from birth. That I've already agreed is
dangerous. But if you start with SHA256, then merged mining is a
trivial fork at least 3 currencies have done successfully.
As said we plan to make Freicoin merge-mineable in the future, and we
expect to get much more security after we do.
The only adverse effect may be a temporary drop in price due to the
new miners selling all the frc they get until a new price equilibrates
with the demand. But that's not really bad for the currency, just to
the holders at that moment.

 Pretty easy to do right now too as the hashing power behind Twister is
 miniscule and probably will stay that way - the only incentive to mining
 is that you get the right to make a promoted post - called a spam
 message in the codebase - that in theory Twister clients are supposed to
 show to their users. Of course, there's absolutely no way to guarantee
 that clients actually do that.

If a system doesn't compensate its miners in a liquid enough way, the
system will probably be insecure, but that's another topic...

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 understanding the system will
 help you understand my thinking behind merge-mining.

 *) It also mentions proof-of-sacrificed-zerocoins which *is* distinct
 because you're sacrificing the thing that the chain is about. Now that
 has some proof-of-stake tinges to it for sure - I myself am not
 convinced it is or isn't a viable scheme.

I'm not sure I understand all the differences between
proof-of-sacrificed-bitcoins and proof-of-sacrificed-newcoins, but I'm
still convinced this doesn't have anything to do with MM PoW vs PoW.
The idea looks very interesting and I will ask you and adam to
understand it better on IRC, but take into account that when you say
merged mining is insecure some people hear merged mined altcoins
are less secure than non-MM altcoins (which is false) and somehow
conclude scrypt altchains are more secure than SHA256 altchains.
Whether we like it or not, many people believe that scrypt, quark or
primecoin PoW algorithms are somehow more secure than SHA256, and
claims that merged mining is insecure from core bitcoin developers
contribute to spread those beliefs and that no new altcoin has been
created with the intend of being merged mined for quite a while.
I'm not trying to make you or anyone here responsible for the mistakes
other people make.

But rephrasing your claims as We're exploring new ideas for altchains
that could be more secure than MM... sounds very different from MM
is insecure, by the way look at this new idea...

 Feel free to ask for corrections in the example if you think it needs
 them.
 Feel free to bring your edge legal cases back, but please try to do it
 on top of the example.

 You're argument is perfectly valid and correct, *if* the assumptions
 behind it hold. The problem is you're assuming miners act rationally and
 have equal opportunities - that's a very big assumption and I have
 strong doubts it holds, particularly for alts with a small amount of
 hashing power.

That's why I made the offer above.
What you point out is the reason why freicoin started without merged
mining, to grow its own independent security first, before starting to
be merged mined.

 You know, something that I haven't made clear in this discussion is that
 while I think merge-mining is insecure, in the sense of should my new
 fancy alt-coin protocol widget use it?, I *also* don't think regular
 mining is much better. In some cases it will be worse due to social
 factors. (e.g. a bunch of big pools are going to merge-mine my scheme on
 launch day because it makes puppies cuter and kids smile)

Fair enough.
Do you see any case where an independently pow validated altcoin is
more secure than a merged mined one?
The reason why I participated in the discussion was that I believe
that merged mined PoW is more secure than
completely-independent-from-bitcoin pow.
And I thought that that was the general understanding in the Bitcoin
development community.

If that's the case, we agree on what's more important to me.

About the new proposal, I don't have a firm opinion yet. I'm sorry but
I have to understand it better and think about it in more depth.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 of questions to be raised and likely drop the
 value of bitcoin as well as all the cryptocurrencies using the same work
 function as dogecoin.

 Right now, there's very little benefit to attacking a significant currency,
 because it would be very expensive and likely traumatize the whole system.
 Unless it's some power like the NSA, I don't think there's much to worry
 about.

The launch thread says it clear: very scrypt, such random, much
profit, wow, many coin.
So it seems that Dogecoin doesn't use SHA256 like Bitcoin, but scrypt
like most of the other scamcoins.
Anyway, I don't see anything in your comment in favor or against
merged mining...

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Merge mining

2014-01-04 Thread Jorge Timón
On 1/4/14, David Vorick david.vor...@gmail.com wrote:
 It's meant to be in favor of merge mining.

 Dogecoin uses scrypt, which is a very popular algorithm.

Also, MS windows is a very popular operative system.
That's a fallacy:
http://en.wikipedia.org/wiki/Argumentum_ad_populum

 If any large
 currency were to be attacked through merge mining, it would probably be
 litecoin miners attacking dogecoin. But if you control enough of the
 litecoin network to do attack mining against dogecoin, you almost certainly
 have a huge vested interest in cryptocurrencies doing well.

Wait, wait, is Dogecoin merge-mineable with litecoin?
It could be if its developers wanted to, but I highly doubt it.
Precisely because of the myths spread against merged mining.

 By attacking
 dogecoin successfully, you'll cast doubt on the entire cryptocurrency
 ecosystem and hurt yourself in the process.

You shouldn't make such assumptions about the interests of a potential attacker.
For example, even being of the cryptocurrency ecosystem I could
consider that their slogans and videos are confusing newcomers and
they're really harming the general image of p2p currencies by
associating them with mad speculation and pump and dump schemes.

Being heavily involved in this ecosystem, I would be very happy if
dogecoin disappeared tomorrow. Personally I've never mined anything,
but if I had the resources I would actually consider such an attack.

Again, I think we're getting off-topic with perrocoin. It hardly 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, and
  a
  significant interest in protecting it. Compromising even something like
  dogecoin would cause a lot of questions to be raised and likely drop
  the
  value of bitcoin as well as all the cryptocurrencies using the same
  work
  function as dogecoin.
 
  Right now, there's very little benefit to attacking a significant
 currency,
  because it would be very expensive and likely traumatize the whole
 system.
  Unless it's some power like the NSA, I don't think there's much to
  worry
  about.

 The launch thread says it clear: very scrypt, such random, much
 profit, wow, many coin.
 So it seems that Dogecoin doesn't use SHA256 like Bitcoin, but scrypt
 like most of the other scamcoins.
 Anyway, I don't see anything in your comment in favor or against
 merged mining...




-- 
Jorge Timón

http://freico.in/

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

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 should check it's own hash.

I'm afraid this is not possible.

 The operating system should check the hash.

There's package management systems like apt-secure that do exactly this.

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] 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 can 51% attack your
  altcoin at negligible cost by re-using existing hashing power.

 I strongly disagree on this isolated point. Using the same logic, Bitcoin
 is
 vulnerable to an attacker at negligible cost by re-using existing hashing

 power from mining Namecoin. Any non-scam altcoin is pretty safe using
 merged
 mining, since any would-be attacker is going to have it in their interests
 to
 invest in the altcoin instead of attacking it. It's only the scam ones
 that
 want to pump  dump with no improvements, that are really at risk here.

 The rational decision for a non-scam altcoin, is to take advantage of
 merged
 mining to get as much security as possible. There are also some possible
 tricks to get the full security of the bitcoin miners even when not all
 participate in your altcoin (but this area probably needs some studying to
 get
 right).

 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 the opportunity cost of mining the currency by
attacking it, just like with Bitcoin.

 Suppose I create a merge-mined Zerocoin implementation with a 1:1
 BTC/ZTC exchange rate enforced by the software. You can't argue this is
 a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the
 only thing you can do with the coin is get some privacy.

The idea of sacrificing something external and make bitcoins appear
still sounds crazy to me.
I don't see how this pegging contributes in anything to a technical
argument against merged mining, just looks like a moral argument
against altcoin in general.

But anyway, if you're going to make bitcoin's validation dependent on
some external chain, it surprises me even more that you prefer that
external dependency to be non-merge mineable.

 But inevitably
 some miners won't agree that enabling better privacy is a good thing, or
 their local governments won't. Either way, they can attack the Zerocoin
 merge-mined chain with a marginal cost of nearly zero.

Ok, so either we assume that the external-pegging hardfork wasn't a
consensus or we just forget about the pegging and go back to talk
about merged mining in general.
Your argument is still for some reason some miners don't like the MM
altcoin and prefer to attack it than to be profitable miners.

If I mine BTC + NMC and you only mine BTC, it will be harder for you
to compete against me: I can afford higher costs than you for the same
BTC reward, since I'm also getting NMC.

What you're saying is that Litecoin is more secure than Namecoin
because while Litecoin can only be attacked by external attackers and
current miners of other scrypt coins, Namecoin can also be attacked
the Bitcoin miners that aren't currently mining Namecoin.
This doesn't sound very reasonable to me.
I think Namecoin is more secure than Litecoin and new coins should be
created with SHA256 and merged mining in mind. At least merged mine
with Litecoin if the still believe scrypt is so anti-ASIC and
centralization-resistant (in fact Litecoin is more centralized than
bitcoin with their shorter block intervals since better connections
are favored, but that's another story).

Merged mining is not only about not competing for proof of work like
Satoshi defended.
It is also about wasting resources: the more mining subsidies to
different chains, the more wasted resources.
By criticizing merged mining you're also indirectly legitimizing the
same scamcoin madness you criticize.
If you don't plan to merge mine, having SHA256 doesn't make sense
because that makes you more fragile to potential bitcoin miners
attacks and chainhopers.
I don't think we would have this many alts living right now if all
proof of work was SHA256.

So if the anti-asic PoW myth and the absurd emerging morals of
GPU-mining as an universal right weren't enough, you want to add an
equally false merged mining is insecure to the collection of
arguments supporting the search of the more absurd possible PoW holy
grail.

Please try to prove that MM is insecure and I'll try to prove your
wrong. But we don't need zerocoin or an artificial pegging to discuss
about this.

I think Namecoin has a lower reward for miners than litecoin and still
has much better security. I haven't run the numbers but, will you deny
it?
How many amazon VMs do you need to attack each one of them?

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 

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 the opportunity cost of mining the currency by
 attacking it, just like with Bitcoin.

 As I showed with my zerocoin example, often that is not the case, e.g. I
 do not support anonymity, or *can't* support it because of the local
 laws.

 Or for that matter, really boring examples like there's two competing
 implementations of some basic idea and we'd rather the winner be picked
 on technical merits rather than I have a grudge and a small pool so
 I'll this upstart at birth

For whatever reason, someone wants to attack one chain, fine.
But if the market is competitive enough and/or the reward of the
MM-coin is high enough comparatively to the biggest ones in the MM
group, then it is not profitable to mine.
If you make a MM coin, it's fees reward are 5% of BTC + NMC rewards,
and a jurisdiction somehow prohibits to mine the new coin (I can't
imagine such a law being enforced, but I'll follow your argument),
then BTC + NMC miners will just tend to disappear from that
jurisdiction.

 It's a thought experiment; read my original post on how to make a
 zerocoin alt-chain and it might make more sense:

 http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html

 Even better might be to use a merge-mined version of Mastercoin as an
 example, where the initial distribution of coins is fixed at genesis and
 forward from that is independent of the Bitcoin blockchain.

I've read it until the end this time, and I have many doubts about
proof of sacrifice as a security mechanism. Although it's certainly
not proof of stake, it smells similarly to me. I'll have to think more
about it.
I still think that link doesn't prove anything against merged mining security.

 I think Namecoin has a lower reward for miners than litecoin and still
 has much better security. I haven't run the numbers but, will you deny
 it?
 How many amazon VMs do you need to attack each one of them?

 I'll give you a hint: marginal cost

Please, don't give me clues and let's discuss the economics, that's
precisely what I want and where I think you're getting it wrong.
Since you refuse to try to prove that MM is less secure, I'll try
myself to prove the opposite.

Let's say we have currencies A, B, C and D, with daily rewards of 70,
20, 10 and 10 valuns respectively.

A, B and C are merged mined, D is not.
So with an equivalent reward to miners and one being merged mined
while the other being independent, what's the more secure chain? C or
D?

Assuming similar hashing algorithms and perfect competition, the cost
of producing enough hashing power to obtain 1 valun in rewards from D
equals the cost of extracting 1 valun in rewards from the group A + B
+ C.
Let's define 1 valun as the costs in energy and capital resources to
produce X GH/s.
So we have the following hashrates for each chain:

A = 100*X GH/s
B = 100*X GH/s
C = 100*X GH/s
D = 10*X GH/s

Now here it comes our attacker paying for amazon servers.
The costs in value to rent a server to produce X GH/s during a day
cannot be lower than 1 valun, given the earlier assumptions. Let's
assume it is equal to 1 valun for simplicity.

So the cost to have 50% of D's hashing power for a day is 10 valuns.
The cost to to have 50% of C's hashing power for a day is 100 valuns,
but, hey, I'll use your hint now.
Marginal costs.
So I'm using 100 valuns to attack C, but I'm still getting my rewards
from A and B as normal.
As normal?
Let's assume it's as normal first.
I would be getting 90 valuns from chains A and B, so 100 - 90 = 10 valuns.
Mhmm, it seems that although I need to make a considerably bigger
investment in the case of attacking C, in the end the total costs will
be the same of attacking D, that is 10 valuns.
But, wait, I've doubled the hashrate!!
Miners were getting 1 valun in reward per valun in mining costs when
the hashrate was 100*X GH/s, now A and B hashrates are 200*X GH/s
because I came to mine.
Some of them will be smart enough to leave fast, but I will be really
getting something between 45 and 90 valuns from honestly mining A + B,
not 90 valuns as I was assuming.
So it turns out that attacking D is actually cheaper than attacking C.

Feel free to ask for corrections in the example if you think it needs them.
Feel free to bring your edge legal cases back, but please try to do it
on top of the example.

PD I'm eager to read your post on BIP32-ish payment protocol, bloom
filters and prefix filters, so I hope I'm not distracting you too much
with this.

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects

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 Piwik or another
free software alternative instead of Google's package.

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Monetary Authority for Bitcoin

2013-12-10 Thread Jorge Timón
On 12/10/13, Ryan Carboni ryan.jc...@gmail.com wrote:
 You're just closed minded.

No, at least to persons have explained you why your proposal is not feasible.
If you wanted to learn, you would have made questions on why those
parts of your proposal are unfeasible.
There have been many proposals about stablecoins in bitcointalk and
other forums (for example, the initial proposals freicoin subforum).
I have participated in several of them trying to find a solution and
I'm now convinced that this is impossible to implement in a secure AND
P2P system.

This is off-topic for this forum, 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 code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2013-12-10 Thread Jorge Timón
This has been asked very recently:

http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development

And a thousand times on bitcointalk.


On 12/10/13, Jameson Lopp jameson.l...@gmail.com wrote:

 no reliance on external data ... depending on various factors (coin
 valuation/exchange rate

 ಠ_ಠ
 --
 Jameson Lopp
 Software Engineer
 Bronto Software

 On 12/10/2013 11:23 AM, Jan Kučera wrote:
 Basically there would be no reliance on external data as the network
 itself
 would decide on reward height and everybody node would be free to do so.
 Each network node would determine the popularity on its own depending on
 various factors (coin valuation/exchange rate, number of transactions and
 many others) and basically come up with its own block reward value.

 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jorge Timón

http://freico.in/

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2013-10-24 Thread Jorge Timón
This will probably sound stupid to most of you, but I'll say it anyway.

The aim of mnemonics is to easily remember, isn't it?
But the approach of removing offensive words is probably
counterproductive to achieving that end. These words cause a greater
emotional impact in our human moral psyches.
If we were willing to use that fact in our advantage to optimize the
maximum unforgettableness criterion, we should actually prefer the
most generally offensive words in that list. Specially if they can
combine with each other to produce more offensive results, basically
the opposite of what we're doing.

Isn't legalize murder dirty jew much easier to remember for most
people than sandwich house yellow cauliflower?

I guess that even if I'm right, this will be hard to explain to users
and I'm not offering myself to do it. So I completely understand if
the people working on this BIP simply ignore this unforgettable
wordlist proposal like if it was just a bad taste joke.
Using the sub-optimal (in terms of human memory) politically correct
wordlist probably won't be that much worse.


On 10/24/13, slush sl...@centrum.cz wrote:
 We've reflected many comments about BIP39 wordlist from the community and I
 think the wordlist is much better now. Specifically we removed many of
 theoretically offensive words as well as we implemented algorithm for
 detecting words with similar characters (cat/eat) and we resolved these
 duplicities. I'm now quite happy with the wordlist and I want to ask you
 for next (final?) round of comments.

 From other features, we added password protection of seed and seed
 hardening (against bruteforcing) using Rijndael cipher. This has been
 chosen because its blocksize can be 128, 192 or 256 bits, so it fits length
 of desired seeds. Also there are Rijndael implementations in every
 language. Btw password protection has one interesting feature - plausible
 deniability. It allows user to have one mnemonic and by using it with
 different passwords, it will generate different BIP32 wallets (wink
 wink)

 I want to be pretty clear that we need to close this topic somehow, because
 we want to use such algorithm in Trezor (which deadline is coming quick)
 and also other wallet developers want to implement such algorithm into
 clients to be compatible with Trezor. There were quite strict requirements
 for such algorithm (like the possibility to convert mnemonic to seed as
 well as seed to mnemonic) and I think we found a good solution. I'm wildly
 asking you for constructive comments, but saying it's a crap, I don't like
 it won't help anything.

 Thanks,
 slush


 On Thu, Sep 12, 2013 at 6:02 PM, Matthew Mitchell 
 matthewmitch...@godofgod.co.uk wrote:

 I removed some more but I haven't added enough back in. It was taking far
 longer than expected so I gave up, but maybe someone else can try to add
 some more:


 https://github.com/MatthewLM/python-mnemonic/blob/master/mnemonic/wordlist/english.txt

 On 12 Sep 2013, at 13:11, Pavol Rusnak st...@gk2.sk wrote:

  On 10/09/13 23:03, Matthew Mitchell wrote:
  Maybe it would have been better without the aggressive words?
 
  I revisited the wordlist and replaced around 67 words that can be
  found offensive in some context.
 
  --
  Best Regards / S pozdravom,
 
  Pavol Rusnak st...@gk2.sk
 
 
 --
  How ServiceNow helps IT people transform IT departments:
  1. Consolidate legacy IT systems to a single system of record for IT
  2. Standardize and globalize service processes across IT
  3. Implement zero-touch automation to replace manual, redundant tasks
 
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 How ServiceNow helps IT people transform IT departments:
 1. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/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/

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk

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

2013-10-21 Thread Jorge Timón
I think it's great to move BIPs to github.
I also agree with the states - directories mapping.
Git manages moved files well.


On 10/21/13, Jean-Paul Kogelman jeanpaulkogel...@me.com wrote:

 On 2013-10-21, at 2:44 AM, Arto Bendiken a...@bendiken.net wrote:


 Indeed. The BIP analogs that immediately come to mind would be the
 enhancement proposal processes for Python, XMPP, and BitTorrent:

 Bitcoin's BIP process is directly based off of Python's PEP process.

 Quote from BIP 1, History:

 This document was derived heavily from Python's PEP-0001. In many places
 text was simply copied 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 the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2013-08-19 Thread Jorge Timón
Removing getwork and the old miner and packaging a better miner seems
the best solution for the reasons already mentioned.

Not directly related, but this remembered me that we planned to
remove the accounting features on freicoin. We don't want to adapt
them for demurrage and we think business shouldn't use it and should
code their own accounting system instead. One that keeps a full log
of the accounting, etc.
Unfortunately the first exchange to support freicoin (cryptonit) used
this feature for accounting user balances on the exchange.

So the question is, is there any good reason to maintain this?
Is any serious business really using this or anyone at all?

I'm talking about removing the following rpc calls:

getaccount
getaddressesbyaccount
getbalance
getreceivedbyaccount
listaccounts
listreceivedbyaccount
move
sendfrom
setaccount

...and modifying these:

getnewaddress
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

http://freico.in/

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2013-07-15 Thread Jorge Timón
One way sacrifice (btc to zerocoin) is a non-issue since there's no
modification required for bitcoin and you can't do anything to prevent
it anyway.
The controversial thing is sacrificing something outside bitcoin's
chain and new btc appearing.

On merged mining. It is true that merged attacking the other chain
is free, but it is still more profitable to just follow the rules and
mine the other coin!!
If someone considers that something he can sell in a market for btc is
negative value...well, he's just dammed stupid. Proof of work is
designed for rational actors, if you stop assuming miners are more or
less rational everything falls apart. It is possible that the extra
value is too little for some miners to bother. But the extra costs of
validating something else are so little compared to chance-hashing
that miners not merged mining namecoin right now are just stupid
(irrational agents). You can merged mine and sell for btc right away.

On prime proof of work...for me it's interseting only because it's
moving towards SCIP-based mining but that should be the goal. Like
Mark said, let's cure cancer while mining. That would end all
mining is wasteful arguments about this great security system. This
would make Ripple's consensus mechanism less attractive. People
talking about new scrypts harder to ASIC-mine when that's the elephant
in the room...
Sorry, I'm going off-topic.
SCIP-based merged mining for the win.



On 7/15/13, Peter Todd p...@petertodd.org wrote:
 On Sat, Jul 13, 2013 at 11:32:39AM -0700, Peter Vessenes wrote:
 One very real issue for alt-currencies that don't peg to Bitcoin is that
 market liquidity is a bitch. By almost all standards current global
 Bitcoin
 liquidity is already very, very low. Too low for many transactions that
 come across my desk at least.

 There are a lot of reasons for that low liquidity, but to try and float a
 new pair for which the likely initial counter-asset is going to be
 Bitcoin
 means minuscule liquidity.

 Being able to have automated Bitcoin-Zerocoin P2P trading without an
 exchange is also significantly more 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/

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2013-07-14 Thread Jorge Timón
I was talking about bi-directional sacrifice.
If zerocoin has it, I want the same on top of freicoin so that btc/frc
can be traded p2p.
Why zerocoin and not the 20 other altchains are going to ask for it?
Ripplers will want it too, why not?

All the arguments in favor of this pegging use zerocoin's point of
view. Sure it would be much better for it, but are additional costs to
the bitcoin network and you cannot do it with every chain.

Merged mining is not mining the coin for free. The total reward (ie
btc + frc + nmc + dvc) should tend to equal the mining costs. But the
value comes from demand, not costs. So if people demand it more it
price will rise no matter how is mined. And if the price rises it will
make sense to spend more on mining.
Bitcoins are worth because it costs to mine them is a Marxian labor
thory of value argument.
It's the other way arround as Menger taught us.


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 is volatile enough.

 Generally the available compute for mining is what it is, adding more
 alt-coins just dillutes the compute available for a given coin.  (Modulo
 different mining functions like scrypt vs hashcash there is some
 non-overlapping available compute because different hardware is more
 efficient, or even cost-effective at all).

 Merge mining is less desirable for the alt-coin - its mining is essentially
 free, on top of bitcoin mining.  Cost free is maybe a weaker starting point
 bootstrapping digital scarcity based market price.

 I think that serves to explain why bitcoin sacrifice as a mining method is
 a
 simple and stable cost starting point for an alt-coin.

I think this could be highly controversial [alt-coin pegging].  Maybe
everybody likes it, but can you expand more on the justifications to peg
the two currencies?

 Bitcoin sacrifice related applications do not require code changes to
 bitcoin itself, which avoids the discussion about fairness of which
 alt-coin
 is supported, and about sacrifice-based pegging being added or not.

 I dont think it necessarily hurts investors in bitcoins as it just creates
 some deflation in the supply of bitcoin.

If you're requiring one chain look at the othe for validations (miners
will have to validate both to mine btc) you don't need the cross-chain
contract, you can do it better.

 You can sacrifice bitcoins as a way to mine zerocoins without having the
 bitcoin network validate zerocoin.  For all bitcoin clients care the
 sacrifice could be useless.

 Bi-directional sacrifice is more tricky.  ie being allowed to re-create
 previously destroyed bitcoins, based on the sacrifice of zerocoin.  That
 would have other coin validation requirements.

 But I am not sure 1:1 is necessarily far from the right price - the price
 is
 arbitrary for a divisible token, so 1:1 is as good as any.  And the price
 equality depends on the extra functionality or value from the
 characteristics of the other coin.  The only thing I can see is zerocoin is
 more cpu expensive to validate, the coins are bigger, but provide more
 payment privacy (and so less taint).  Removing taint may mean that zercoins
 should be worth more.  However if any tainted bitcoins can be converted to
 zerocoin via sacrifice at 1:1, maybe the taint issue goes away - any coins
 that are tainted to the point of value-loss will be converted to zerocoin,
 and consequently the price to convert back should also be 1:1?

You could do something like this:

https://bitcointalk.org/index.php?topic=31643.0

 p2p transfer is a good idea.

 Adam



-- 
Jorge Timón

http://freico.in/

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2013-07-13 Thread Jorge Timón
 assuming support for non-single-zerocoin amounts) and whatever chain has
 the highest total sacrifice wins. One way to think about
 proof-of-sacrifice is it's really proof-of-work, transferred. It also
 has the *big* advantage that to double-spend, or for that matter 51% the
 chain, you have to outspend everyone with a stake in the viability of
 the blockchain: they can sacrifice their zerocoins to combat you. In the
 case of a double-spend to rip off an online merchant the total amount
 you could profit is the same as the total amount they would rationally
 spend to stop you, and soon there will be collateral damage too
 increasing the amount third-parties are willing to sacrifice to stop
 you. You can't win.

 Of course, this does mean that even unsuccesful sacrifices need to be
 costly. You can make this acceptable to users by allowing a sacrifice to
 be reused, but only for the exact same transaction it was originally
 committed to.

 Sacrifices in this manner are *not* proof of stake. You really are
 giving up something by publishing the information that proves you made
 the sacrifice as that information can always be included in the
 consensus thereby taking away a limited resource. (your zerocoins) It's
 more heavily dependent on jam-free networks, and doesn't play nice with
 SPV, but zero-knowledge proofs will may help the latter. (you've got
 Bitcoin itself to act as a random beacon remember)

 Speaking of, another similar approach is to take advantage of how a
 Bitcoin sacrifice can be made publicly visible. Create a txout of some
 value like the following:

 OP_RETURN prev-ztc-blockhash blockhash ztc-created

 Now even if you fail to publish your blocks, at least the whole world
 knows how much they need to outspend to be sure you can't 51% attack the
 network. This approach and not-btc sacrifices can go hand in hand too,
 especially if nodes follow rules where they consider btc txout
 sacrifices as fixed and only subject to change by the bitcoin
 blockchain re-organizing. Advantages and disadvantages to both
 approaches. (remember that visible tx's can be censored by miners)

 Sacrifice to mining fees may be acceptable in the future too, but only
 if OP_DEPTH is implemented so as to not give Bitcoin miners bad
 incentives. (the sacrificed coins should go to fees *months* or even
 *years* after they have been sacrificed)

 Turning zerocoins back into Bitcoins is just supply and demand: sell
 them. You'll always lose a bit given by definition the maximum exchange
 rate is 1:1, but anonymity may be worth it. Others have written about
 cross-chain trading protocols, and I'll point out they are easier to
 implement if one chain has full visibility into what's happening on the
 other; zerocoin is most likely to be implemented as an extension to the
 bitcoin client itself.

 Finally if the transaction rate is too slow there's nothing wrong with
 running multiple parallel zerocoin blockchains, although given the
 usecase of moving your funds through zerocoin for anonymity, and using
 the clean coins that come out the other side, there's 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/

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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, but it seems to me that
 having different characteristics, bitcoins and zerocoins would be
 different currencies.
 I don't see the need to peg zerocoins to bitcoins.
 It is great to have an anonymous p2p currency, maybe some bitcoin
 users that use bitcoin because of the transparency they allow (public
 funds expenditures could be more transparent than they have ever been)
 don't like this hard-fork. Well, maybe this is not the main reason,
 but I think this could be highly controversial.
 Maybe everybody likes it, but can you expand more on the
 justifications to peg the two currencies?
 If you're requiring one chain look at the othe for validations (miners
 will have to validate both to mine btc) you don't need the cross-chain
 contract, you can do it better.

 Instead of doing this:

 https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains

 You could do something like this:

 https://bitcointalk.org/index.php?topic=31643.0

 This very idea has been proposed recently by othe people, but I can't
 find where.

 The problem with this is of course scalabilty. Once you do it for what
 chain, why not the others?
 You can't validate 100 chains to mine bitcoin even if they're all
 merged mined: that's asking miners too much.
 If zerocoin enjoys this privilege why not, for example?

 As some of you may know, Mark Friedenbach and I are working on a
 protocol modification to support issuance of arbitrary assets. Would
 be something like colored coins but better, we're calling it
 FreiMarkets. Of course these assets are not p2p like bitcoin or
 freicoin themselves: they have a centralized issuer.
 But if you allowed to sacrifice real bitcoins (as opposed to IOUs
 denominated in BTC like you have, for example, in ripple) so they
 appear in Freicoin's chain and turn them back, you could have p2p
 bitcoins inside Freicoin's chain.
 Maybe ripplers want that too. If FreiMarkets prove to work well on
 freicoin and be scalable enough, maybe a lot of scamcoins apply the
 hardfork too and they want to have p2p btc in their chain as well.

 Maybe I could have explained this without even mentioning FreiMarkets,
 but my point is that you're asking for a lot like it was nothing.
 Zerocoin-bitcoin fungibility hardfork is opening a little pandora's
 box. Are we ready?

 I was waiting for others to comment and I'm surprised that no one else
 has made any objection yet. But if no one's going to point out the
 controvery that is so obvious to me, I feel almost like a
 responsability to act like a Devil's advocate here.
 So if you make bitcoin and zerocoin fungible, I want bitcoins to be
 transferrable to freicoin's chain. And I warn you there will be many
 more people asking for the same thing on other chains. What criteria
 will we have to say yes or no?
 More



 On 7/12/13, Peter Todd p...@petertodd.org wrote:
 On Fri, Jul 05, 2013 at 04:01:40PM +0200, Adam Back wrote:
 Do people think that should work?  It seems to me it should with
 minimal,
 bitcoin changes.  I think the rule for either-or mining should be as
 simple
 as skipping the value / double-spend validation of the blocks that are
 zerocoin mining blocks.  Obviously zerocoin blocks can themselves end up
 on
 forks, that get resolved, but that fork resolution can perhaps be
 shared?

 (Because the fork resolution is simply to accept the longest fork).

 Yeah, there's been a lot of doom and gloom about zerocoin that is
 frankly unwarrented. For instance people seem to think it's impossible
 to make a blockchain with zerocoin due to the long time it takes to
 verify transactions, about 1.5 seconds, and never realize that
 verification can be parallelized.

 Anyway the way to do it is to get out of the model of large blocks and
 think about individual transactions. Make each transaction into its own
 block, and have each transaction refer to the previous one in history.
 (zerocoin is inherently linear due to the anonymity)

 Verification does *not* need to be done by every node on every
 transaction. Make the act of creating a transaction cost something and
 include the previous state of the accumulator as part of a transaction.
 Participants verify some subset of all transactions, and should they
 find fraud they broadcast a proof. Optionally, but highly recomended,
 make it profitable to find fraud, being careful to ensure that it's
 never profitable to create fraud then find it yourself.

 Anyway Bitcoin is limited to 7tx/s average so even without probabalistic
 verification it'd be perfectly acceptable to just limit transactions to
 one every few seconds provided you keep your blocksize down to one
 transaction so the rate isn't bursty. You're going to want

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

2013-04-10 Thread Jorge Timón
On 4/10/13, Peter Todd p...@petertodd.org wrote:
 Oh, and while we're at it, long-term (hard-fork) it'd be good to change
 the tx hash algorithm to extend the merkle tree into the txouts/txins
 itself, which means that to prove a given txout exists you only need to
 provide it, rather than the full tx.

 Currently pruning can't prune a whole tx until every output is spent.
 Make that change and we can prune tx's bit by bit, and still be able to
 serve nodes requesting proof of their UTXO without making life difficult
 for anyone trying to spent old UTXO's. The idea is also part of UTXO
 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 is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-13 Thread Jorge Timón
I'm not sure I understand your proposal, but its sounds good.
Can you elaborate with an example?
Are you considering colored coins/smart property?


On 3/13/13, Stephen Pair step...@bitpay.com wrote:
 Instead of thinking in terms of blocking uneconomical transactions (how
 would a node even determine what's economical?), what about thinking in
 terms of paying for a feed of economical (i.e. profitable) transactions?
 There is a market for fee bearing, profitable transactions...if there is no
 one willing to pay to receive a transaction, then no one will bother
 propagating it.  Such a system would make it possible to determine the
 probability of confirmation in a given timeframe for a given fee.


 On Tue, Mar 12, 2013 at 3:49 AM, Peter Todd p...@petertodd.org wrote:

 On Sat, Mar 09, 2013 at 11:31:55PM -0500, Peter Todd wrote:
  As discussed endlessly data in the UTXO set is more costly, especially
  in the long run, than transaction data itself. The fee system is per KB
  in a block, and thus doesn't properly capture the long-term costs of
  UTXO creation.

 There's been a lot of discussion about this issue, and many people have
 asked that Bitcoin not arbitrarily block interesting potential uses of
 provably unspendable txouts for data applications, and similarly
 spendable txouts representing assets. I've changed my hardline position
 and now think we should support all that stuff. However, there is one
 remaining class of txout not yet talked about, unspendable but not
 provably so txouts. For instance we could make the following a standard
 transaction type:

 scriptPubKey: OP_HASH160 20 byte digest OP_EQUALVERIFY data
 scriptSig: data

 Of course, usually the 20 byte digest would be picked randomly, but it
 might not be, and thus all validating nodes will always have a copy of
 the data. With the 10KB limit on script sizes you can fit 9974 bytes of
 data per transaction output with very little waste.

 A good application is timestamping, with the advantage over
 coinbase/merkle tree systems in that you don't have to wait until your
 timestamp confirms, or even store the timestamp at all. Another
 application, quite possible with large block sizes and hence cheap or
 free transactions, is secure data backups. In particular such a service,
 perhaps called Google Chain Storage, can offer the unique guarantee that
 you can know you're data is secure by simply performing a successful
 Bitcoin transaction.

 --
 'peter'[:-1]@petertodd.org


 --
 Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
 Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
 endpoint security space. For insight on selecting the right partner to
 tackle endpoint security challenges, access the full report.
 http://p.sf.net/sfu/symantec-dev2dev
 ___
 Bitcoin-development mailing list
 Bitcoin-development@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-project.org/

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-11 Thread Jorge Timón
That solution seems good enough to me.
Smartcoin users would just need to move their assets before 10 years,
totally acceptable.
And regular users don't need to think about it since they're probably
always sending more than they pay in fees.


On 3/11/13, Benjamin Lindner b...@benlabs.net wrote:

 On Mar 11, 2013, at 12:54 PM, Mike Hearn m...@plan99.net wrote:
 With regards to trying to minimize the size of the UTXO set, this
 again feels like a solution in search of a problem. Even with SD
 abusing micropayments as messages, it's only a few hundred megabytes
 today. That fits in RAM, let alone disk. If one day people do get

 The problem of UTXO in principal scales with the block size limit. Thus it
 should be fixed BEFORE you consider increasing the block size limit.
 Otherwise you just kick the can down the road, making it bigger.

 concerned about the working set size, miners can independently set
 their own policies for what they confirm, for instance maybe they just

 Problem is the skewed incentive structure. Rational miners will always
 include dust output with fees, because the eternal cost of UTXO is payed by
 the network and future miners, not the current/individual 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 of measurement.

 As said on the bitcointalk thread, I think this is the wrong approach.
 This way you effectively disable legitimate use cases for payments
 that are worth less than the fees like smart property/colored coins.

 this.

 Just activate a non-proportional
 demurrage (well, I won't complain if you just turn bitcoin into
 freicoin, just think that non-proportional would be more acceptable by
 most bitcoiners) that incentives old transactions to be moved

 You could delegate the decision to the user with a rule like:

 if (outputfee):
  limit lifetime of the UTXO to 10 years.
 if (outputfee):
  unlimited lifetime

 Then, when a user creates a transaction, he can decide whether he wants to
 have limited or unlimited lifetime. The rationale for limiting the lifetime
 for (outputfee) transactions is that they may have no inherent economic
 incentive to be spend.


 --
 Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
 Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the
 endpoint security space. For insight on selecting the right partner to
 tackle endpoint security challenges, access the full report.
 http://p.sf.net/sfu/symantec-dev2dev
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jorge Timón

http://freico.in/
http://archive.ripple-project.org/

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Can this tx be formed?

2013-03-11 Thread Jorge Timón
Say Alice signs and broadcasts a tx with input Ai, with SIGHASH_SINGLE
to Ao and SIGHASH_ANYONECANPAY
Bob signs and broadcasts a tx with input Bi, with SIGHASH_SINGLE to Bo
and SIGHASH_ANYONECANPAY

Can Carol complete the tx so that it is valid to be published in the chain?
It only has to make Ai + Bi + Ci + F = Ao + Bo + Co
but it all must be contained in a single transaction.

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Key retirement and key compromise

2013-02-25 Thread Jorge Timón
Just create a new wallet and send everything to a new address.
I don't think additional tools for this are needed.


On 2/23/13, Roy Badami r...@gnomon.org.uk wrote:
 Has anyone been thinking about providing tools to allow users to cope
 with key compromise - or more generally, to manage key retirement etc?

 atm, if you suspect that your keys may be liable to compromise then
 what would you have to do?  You'd have to create a new wallet (on a
 new computer?  or is it easy to have two coexisting installs on one
 computer?)  And then you'd have to make one or more payments from the
 old wallet to the new wallet, to transfer the coins.  It's a pain, and
 you've lost your address book, your transaction history, etc.  And
 unless you keep the old wallet about, too, you're a bit stuck if
 someone makes a payment to one of the old addresses.  It's something
 that most users would baulk at unless they're really sure they're at
 significant risk.

 Of course, there are a spectrum of scenarios, ranging from having an
 unencrypted wallet stolen by someone who knows what it is, through to
 deciding that the passphrase you used to use when you only had a few
 dollars worth of BTC maybe isn't good enough now you've got tens of
 thousands of dollars worth of coins.  Or maybe you have no reason to
 suspect there is a risk of compromise, but just have a corporate key
 management policy that recommends retiring keys after a period of
 time.

 What would be really nice is for bitcoin to have a big key compromise
 button, which would automatically transfer all coins to newly
 generated addresses (optionally with a pause between generation and
 transaction - to allow for a new wallet backup).  Optionally, too, the
 compromised/retired addresses could be marked with a flag such that if
 someone sends coins to that address bitcoind immediately generates a
 transaction to transfer the coins to address(es) which are good.

 I know deterministic wallets have many proponents - but personally I
 like having a bag of keys - with the idea that over a period of time,
 old keys will routinely be retired and their balances automatically
 transfered to newly generated keys.  If someone really manages to
 crack the passphrase on that 10-year-old wallet backup they got hold
 of, then if would be nice to minimise the damage they could do...

 And, of course, I want a big panic button that allows me to
 automatically transfer all my coins to new addresses ASAP if I
 suddenly do something stupid, like accidentally type my passphrase
 into my IRC window :-)

 Thoughts?  Is this functionality that there is any interest in
 developing within the official client?  If there is any interest in
 this then obviously the first step would be to specify exactly what
 functionality is wanted...

 roy

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_feb
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



-- 
Jorge Timón

http://freico.in/
http://archive.ripple-project.org/

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Implementing trading across chains

2013-02-13 Thread Jorge Timón
Well, if it's even possible to trade across chains with Ripple (and
I don't know of any reason shouldn't be), you will have to wait to the
release of the full node (validator) code, for now only a javascript
web client is open sourced. But it seems they at least have plans for
contracts judging from the wiki:

https://ripple.com/wiki/Contracts


On 2/13/13, Petr Praus p...@praus.net wrote:
 Jorge, thanks for bitcoinx tip, I didn't know about it and it's certainly
 related. I'll have a closer look
 Regarding Ripple, I tried it but as far as I can tell, it doesn't have any
 contract enforcement (by technical means) built in.


 On 11 February 2013 05:03, Jorge Timón jtimo...@gmail.com wrote:

 Hi, you may be interested in a couple of related projects.

 Colored coins uses satoshis to represent smart property, shares, IOUs
 of another currency...Colored coins can be atomically traded for
 bitcoin. If you implement the trade across chains contract they would
 also be tradeable for another chain currencies like namecoin or
 freicoin.

 http://www.bitcoinx.org/

 Ripple is a concept by which people that trust each other on a network
 are able to pay with IOUs transitively. It has a new p2p
 implementation  that is still on development. The new implementation
 is very similar to bitcoin in certain senses but it has no mining.
 Bitcoin IOUs can be traded there.

 https://ripple.com/

 Good luck with the implementation, this is a good feature to have,
 even if it's not on the main client.


 On 2/8/13, Petr Praus p...@praus.net wrote:
  Hi,
 
  I intend to implement trading across chains in a P2P manner (as
  described
  by Mike Hearn in
  https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains).
  Note, this is indended more as an alternative chain development, I
  don't
  have any plans for merging it back into main client (not because I
  don't
  want to, but because I think it wouldn't be accepted). Before I dive
  into
  it, I thought it might be a good idea to ask here if the community has
 any
  useful ideas or comments on this topic?
 
  Thanks to Gary Rowe I know about Open
  Transactionshttps://github.com/FellowTraveler/Open-Transactions.
  They can do multicurrency trading too, but it's objectives are quite
  ambitious and I'm looking at making relatively small changes in the
  mainline Bitcoin client rather than diving into something entirely new.
 
  A little background on why am I doing this, can be found
  herehttps://groups.google.com/d/topic/bitcoinj/lmVSF8yaJHk/discussion.
  In short it's part of research towards my Master's thesis (more
 precisely,
  an excuse to hack on Bitcoin and sell it as research :)) which should
  be
  about multicurrency (alternative chains) in Bitcoin.
 
  Thanks,
  Petr
 
  PS: I hope I'm not too off topic here, but
  thishttps://bitcointalk.org/index.php?topic=15527.0 thread
  indicates it should be fine to post alternative development questions
  on
  this.
 


 --
 Jorge Timón

 http://freico.in/
 http://archive.ripple-project.org/




-- 
Jorge Timón

http://freico.in/
http://archive.ripple-project.org/

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


  1   2   >