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
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/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
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/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, 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
>
> 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
" 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
and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> ___
> Bitcoin-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
-
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
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
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, 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,
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
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,
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
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 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
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, 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 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 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 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
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 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
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
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
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
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
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
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
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
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
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
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
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.
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
>>
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
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
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 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 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 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 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 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
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
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
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
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
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 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.
---
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 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
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 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.
>
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 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 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 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
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 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
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
-- 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 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
gt; This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> ___
> Bitcoin-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo
On 4/12/12, Jeff Garzik wrote:
> 1. N = 1 or 2 or whatever the community prefers. Ideally enough time
> for a third-tier miner, mining strange TXs, finds a block.
> 2. H1 = height of block chain, when a TX is received
> 3. H2 = H1 + (144 * N)
> 4. If block chain height reaches H2, and TX has
ed him that I haven't really used them.
It would be nice to also have a list with smartphone clients near the
list that is being prepared.
--
Jorge Timón
--
Live Security Virtual Conference
Exclusive live event will
05/03/2012 11:24 AM, Jorge Timón wrote:
>> On 5/3/12, Andreas Schildbach wrote:
>>> Can we add Bitcoin Wallet?
>>
>> Someone said to me that the cell phone apps they had tried were still
>> too slow. I'm still using an old phone so I didn't know well
2/114/50122263/
>>
>
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers
your code?
> 3 out of 4 devs don\\\'t know how their code performs in production.
> Find out how slow your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219672;13503038;z?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
es, SIGHASH_ALL was the crucial piece I was missing.
Great, there's no need for an additional SIGHASH.
I guess you're implementing the simple case you describe first.
Do you plan to implement the more general case with n participants
instead of only 2 (a Ripple transaction)?
That would be
On 9/23/12, Jeff Garzik wrote:
> - provides a deterministic lifetime for a TX; if you KNOW a TX will
> disappear 144 blocks (24 hours) after you stop transmitting, then it
> is probably safe to initiate recovery procedures and perhaps revise
> the transaction
> - prevents zombie TXs from littering
ut multicurrency (alternative chains) in Bitcoin.
>
> Thanks,
> Petr
>
> PS: I hope I'm not too off topic here, but
> this<https://bitcointalk.org/index.php?topic=15527.0> thread
> indicates it should be fine to post alternative development questions on
> this.
>
l, it doesn't have any
> contract enforcement (by technical means) built in.
>
>
> On 11 February 2013 05:03, Jorge Timón wrote:
>
>> Hi, you may be interested in a couple of related projects.
>>
>> Colored coins uses satoshis to represent smart property, shares,
gt; 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/appd
On 3/10/13, Peter Todd 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
e a non-proportional demurrage
>
> demurrage of any kind will never, ever happen, just give up on that idea.
>
> The negative publicity of "the bitcoin developers are destroying YOUR
> coins!" would be dev
Unless of course everlasting physical "bitcoins" are much more
important than smart property and colored coins...
On 3/11/13, Jorge Timón wrote:
> "The Bitcoin network will destroy your coins IF you don't move your coins"
> Is pretty different. By the way, do
nodes don't go unresponsive when somebody
> downloads the chain from them, and finishing the payment protocol work
> so there's less incentive to replicate the SD "transactions as
> messages" design.
>
--
Jorge Timón
http://freico.in/
http://archive.ripple-project.org/
TXO is payed by
> the network and future miners, not the current/individual miner.
>
> On Mar 11, 2013, at 7:01 AM, Jorge Timón wrote:
>
>> On 3/10/13, Peter Todd wrote:
>>> It's also been suggested multiple times to make transaction outputs with
>>> a value
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 +
On 3/12/13, Mike Hearn wrote:
> 1) Start aggressively trying to block or down-prioritize SatoshiDice
> transactions at the network level, to buy time and try to avoid
> mempool exhaustion. I don't know a good way to do this, although it
> appears that virtually all their traffic is actually coming
> 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
> [email protected]
ev
>> _______
>> Bitcoin-development mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> --
> Stephen Pair, Co-Founder, CTO
'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/
--
ourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--
Jorge Timón
http://freico.in/
--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT de
ritten 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.
>
> F
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 wrote:
> I'm not sure I understand the whole proposal, but i
as Menger taught us.
On 7/13/13, Adam Back 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 stabl
-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
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 bitco
o compare against HyperLevelDB, where the differences are much less
> pronounced and actually HyperLevelDB appears to be able to do random writes
> faster than Sophia.
>
--
Jorge Timón
http://freico.in/
--
LIMITED
On 9/17/13, Mike Hearn 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 inc
ely 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.
tps://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. Standard
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 a
isibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> ___
> Bitcoin-development mailing list
> Bitcoin-dev
On 12/31/13, Mike Hearn 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 anoth
On 1/3/14, Troy Benjegerdes 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 o
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
