On Sun, Jun 21, 2015 at 12:08 AM, Tier Nolan wrote:
> The off by 1 bug could be fixed by a soft fork. Since the point is to show
> how a non-controversial hard fork works, it doesn't matter much.
You mean the timewarp fix can be coded as a softfork instead of a
hardfork? How so?
If that's the ca
-- Forwarded message --
From: "Jorge Timón"
Date: Jun 17, 2015 6:59 PM
Subject: Re: [Bitcoin-development] [RFC] Canonical input and output
ordering in transactions
To: "Rusty Russell"
Cc:
On Tue, Jun 16, 2015 at 10:06 AM, Rusty Russell
wrote:
> Jorge Timó
On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo wrote:
> If we want a non-repudiation mechanism in the protocol, we should explicitly
> define one rather than relying on “prima facie” assumptions. Otherwise, I
> would recommend not relying on the existence of a signed transaction as proof
> of i
On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo wrote:
> The Bitcoin network was designed (or should be designed) with the requirement
> that it can withstand deliberate double-spend attacks that can come from
> anywhere at any time…
I disagree with this premise. Please, don't take this as an ar
This is an attempt to unify views on why and how hardforks can be
deployed. I would like to turn this into an informational BIP later
after gathering some feedback.
Please, do not discuss block size issues here: there's plenty of
threads to do so. The scope of this one is only hardforks and
softfo
On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn 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
On Thu, Jun 18, 2015 at 8:23 PM, Gavin Andresen wrote:
> On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos wrote:
>>
>> Let me take a pass at explaining how I see this.
>>
>> 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is
>> the decider but he works under a process that is w
On Tue, Jun 16, 2015 at 2:08 AM, Aaron Voisine wrote:
>
> hell even some major changes to the non-consunsus code to make it
adequately handle the situation when blocks fill up
This will have to eventually be done in addition to any other "alternative"
unless the plan is to keep rising the limit
On Jun 15, 2015 11:43 PM, "Rusty Russell" 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 orderi
On May 31, 2015 5:08 PM, "Gavin Andresen" wrote:
>
> On Sun, May 31, 2015 at 10:59 AM, Jorge Timón 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.
>
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"
On May 30, 2015 10:38 PM, "Gavin Andresen" wrote:
>
> Mining is a competitive business, the marginal miner will ALWAYS be going
out of business.
>
> That is completely independent of the block size, block subsidy, or
transaction fees.
No, the later determines who can be profitable.
Here's a thoug
On May 27, 2015 12:58 PM, "Peter Todd" 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 nLoc
On May 27, 2015 11:35 AM, "Tier Nolan" 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.
---
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" wrote:
> On Wednesday, May 27, 2015 1:48:05 AM Pieter Wuille wrote:
> > Feel free to comment. As the gist does not support notifying
On Wed, May 13, 2015 at 12:31 PM, Alex Mizrahi 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 ge
On Mon, May 11, 2015 at 7:29 PM, Gavin Andresen 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
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
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
On Thu, May 7, 2015 at 6:59 PM, Gavin Andresen 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
On Thu, May 7, 2015 at 6:11 PM, Mike Hearn 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 ;)
>
On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen 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 t
On Thu, May 7, 2015 at 4:05 PM, Mike Hearn 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 pr
On Thu, May 7, 2015 at 1:55 PM, Dave Hudson wrote:
> Known: There has been a steady trend towards the mean block size getting
> larger. See
> https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=
Looking at this graph
On Thu, May 7, 2015 at 1:29 PM, Mike Hearn 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-357
On Thu, May 7, 2015 at 11:25 AM, Mike Hearn wrote:
> I observed to Wladimir and Gavin in private that this timeline meant a change
> to the block size was unlikely to get into 0.11, leaving only 0.12, which
> would give everyone only a few months to upgrade in order to fork the chain
> by the e
2);
> }
>
> if (!tx.vin[i].IsFinal() && tx.vin[i].scriptSig.IsSequenceAsRelativeHeight()
> && nSpendHeight < coins->nHeight + tx.vin[i].nSequence)
>return state.Invalid(false, REJECT_INVALID,
> "bad-txns-non-final-input");
This gives you le
t the timestamp
discussion is quite orthogonal to the nSequence-based RCLTV proposal
itself.
On Tue, May 5, 2015 at 2:41 AM, Btc Drak wrote:
> On Mon, May 4, 2015 at 12:24 PM, Jorge Timón wrote:
>>
>> What I was describing was an attempt to fix a similar proposal by Mark
>>
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.
erstand 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 :
>>
>> As Mike says it depends on your interests. But one thing that is almost
>> always we
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 ca
Forget it, sorry, I misunderstood the proposal entirely, re-reading
with more care...
On Tue, Apr 28, 2015 at 2:41 PM, Kalle Rosenbaum 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
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" wrote:
> On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote:
> > On Sun, Apr 26, 2015 at
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" wrote:
> "Or a really high lock_time, but it would not make it invalid, just
> delay
On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón wrote:
> There's another possibility that could keep the utxo out of Script
> verification:
>
> class CTxIn
> {
> public:
> COutPoint prevout;
> CScript scriptSig;
> uint32_t nSequence;
> }
>
> coul
On Tue, Apr 21, 2015 at 9:59 AM, Peter Todd 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 distin
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
Oh, no, sorry, it also covers bip62.
On Fri, Apr 24, 2015 at 10:55 AM, Jorge Timón 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
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
On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik 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 t
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 pay
On Thu, Feb 19, 2015 at 6:30 PM, Mike Hearn 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
> di
On Thu, Feb 19, 2015 at 3:09 PM, Tamas Blummer wrote:
> On Feb 19, 2015, at 3:03 PM, Bryan Bishop 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
On Sat, Feb 14, 2015 at 3:23 PM, Tamas Blummer 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, wall
On Sun, Jan 4, 2015 at 7:31 PM, Gregory Maxwell wrote:
> Thanks for presenting your solution as code in any case. It really is a useful
> way to communicate and I wish more people did that.
+1
--
Dive into the World of P
On Mon, Dec 29, 2014 at 10:34 PM, Justus Ranvier
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 tran
On Sun, Dec 21, 2014 at 5:07 PM, Peter Todd 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 s
st
On Sun, Dec 21, 2014 at 6:52 AM, Peter Todd 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
On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon
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 th
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 wrote:
> I agree with Luke, we can endlessly discuss the "best defaults" like
> the default size allowed for OP_RETURN,
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
On Mon, Nov 3, 2014 at 5:01 PM, Alex Mizrahi 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,
On Mon, Nov 3, 2014 at 1:12 PM, Alex Mizrahi 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
>
>
> Ha
On Mon, Oct 6, 2014 at 1:40 AM, Gregory Maxwell 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
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 Professio
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
-
" if you prefer), and although it's not
ready yet, some people may be interested or may want to give some
feedback:
https://github.com/jtimon/bitcoin/tree/proof
I don't know if it will make it into master, but by specializing
ProofOfWork with TestnetProofOfWork we could remove
Para
>
> 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 a
On 6/24/14, Justus Ranvier 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, id
On 6/24/14, Tamas Blummer 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
On 6/24/14, Mike Hearn 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
On 6/23/14, Wladimir wrote:
> It's least surprising if the wallet works as a SPV client by default.
> Then, users can use it without first setting up a core. Thus the idea
> would be to use P2P primarily.
So first bitcoind will support SPV mode then we separate the wallet?
Are the core and the wa
e
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. Sim
On 6/16/14, Mike Hearn 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 collecti
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.
Th
On 4/24/14, Mike Hearn 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,
On 4/24/14, Mike Hearn wrote:
>>
>> This scheme would discourage people from attempting a Finney attack
>> because they would end up worse off if they did.
>>
> Phrased another way, it simply makes every block a Finney attack that
> charges the maximum double spending fee possible. This doesn't so
On 4/24/14, Peter Todd 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 par
On 4/24/14, Mike Hearn 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 po
iners 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 exa
7;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 o
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/
-
tcoind. 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
&quo
On 4/17/14, Mike Hearn 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
On 4/17/14, Gavin Andresen wrote:
> How is this different from just running in -regtest mode and asking the
> nodes to generate a block after 1 or 2 seconds?
There's no difference, the -timedtest mode does exactly that. But
automatically instead of having to manually ask for a new block every
sec
ement 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 - Do
On 4/7/14, Flavien Charlon 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 compan
On 4/7/14, Flavien Charlon 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 s
On 4/5/14, Matt Whitlock 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 i
angelist
> BitPay, Inc. https://bitpay.com/
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/list
gt;>___
>>Bitcoin-development mailing list
>>Bitcoin-development@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
http://freico.in/
-
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 co
On 3/22/14, Peter Todd wrote:
> Well remember that my thinking re: UTXO is that we need to move to a
> system like TXO commitments where storing the entirety of the UTXO set
> for all eternity is *not* required. Of course, that doesn't necessarily
> mean you can't have the advantages of UTXO commi
n 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?
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/freima
On 3/13/14, Mike Hearn 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 a
On 3/13/14, Troy Benjegerdes wrote:
>
>
> 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 roll
>> >> > 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
>> &g
ibility 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 t
tc.
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
imple
> plain language what an 'embedded consensus system' is to the distributed
> de-centralized local court systems.
>
> --
> Managing the Performance of Cloud-Based Applicatio
--
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>&
On 1/10/14, Peter Todd wrote:
> Because there aren't that many pools out there and Ixcoin (and devcoin)
> appear to have been lucky enough to servive long enough to get the
> support of a reasonably big one. Once you do that, the potential
> attackers have PR to think about. (namecoin especially h
On 1/10/14, Peter Todd 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
On 1/10/14, Peter Todd 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
On 1/6/14, Peter Todd 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 underst
ch 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 wrote:
>
>> On 1/4/14, David Vorick wrote:
>> > If you have the resources to attack one of the bigger altcoins, you
>
On 1/4/14, David Vorick 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
On 1/3/14, Peter Todd 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.
&
On 1/1/14, Peter Todd 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%
1 - 100 of 158 matches
Mail list logo
