On Tue, Nov 5, 2013 at 2:15 PM, Drak wrote:
> If I understand the issue properly, this seems like a pretty elegant
> solution: if two blocks are broadcast within a certain period of eachother,
> chose the lower target. That's a provable fair way of randomly choosing the
> winning block and would s
On Fri, Nov 8, 2013 at 11:49 AM, Andreas M. Antonopoulos
wrote:
> Nicholas Weaver is reporting that pools have already started delaying
> blocks, something that hints at Selfish Mining, since Nov. 3rd.
> https://medium.com/something-like-falling/d321a2ef9317
>
> He dismisses other reasons for dela
On Fri, Nov 15, 2013 at 1:54 AM, Peter Todd wrote:
> \documentclass{article}
LaTeX moon language to PDF moon language conversion:
https://people.xiph.org/~greg/peter_todd_mining_ev.pdf
--
DreamFactory - Open Source REST
On Mon, Jul 22, 2013 at 2:37 PM, Jean-Paul Kogelman
wrote:
>
> I added a 2 byte 'weeks since 2013-01-01' field and updated the prefixes,
> ranges and test vectors.
>
> The updated proposal lives here:
> https://bitcointalk.org/index.php?topic=258678
Greetings. Any recent progress on this?
Do we
On Tue, Nov 19, 2013 at 8:53 AM, Drak wrote:
> It's quite normal for standards bodies to allocate numbers when in draft
> status. If they don't pass, they don't pass - they are clearly labelled
> DRAFTs.
>
> +1 on having things in a github repository. Much better for collaboration,
The IETF makes
On Tue, Nov 19, 2013 at 9:45 AM, Wladimir wrote:
> Talking about complete, BIP 40 and 41 don't even have an associated
> document:
> https://github.com/bitcoin/bips
> I agree that was over-eager number assigning.
Maybe! The subject matter its assigned for is already _widely_
deployed, for better
On Fri, Nov 22, 2013 at 12:49 PM, Jeff Garzik wrote:
> Whitelist nodes against banning.
Is there a reason not to have a parallel get rpc to get the current list?
--
Shape the Mobile Experience: Free Subscription
Software
On Sun, Nov 24, 2013 at 8:20 AM, Christian Decker
wrote:
> Since this came up again during the discussion of the Cornell paper I
> thought I'd dig up my measurement code from the Information
> Propagation paper and automate it as much as possible.
Could you publish the block ids and timestamp set
On Sun, Dec 8, 2013 at 2:00 AM, Drak wrote:
> There is really no excuse for not using an SSL certificate. Without one it
> would be trivial for an attacker to change the contents of the page via
> MITM.
Having control of the site gives you a cert regardless, as several CAs
will issue a cert to an
On Sun, Dec 8, 2013 at 11:16 AM, Drak wrote:
> BGP redirection is a reality and can be exploited without much
You're managing to argue against SSL. Because it actually provides
basically protection against an attacker who can actively intercept
traffic to the server. Against that threat model SSL
On Sun, Dec 8, 2013 at 12:28 PM, Mike Hearn wrote:
> Right now I think Sirius still owns DNS for bitcoin.org which is nonsense.
> He needs to pass it on to someone who is actually still involved with the
> project. Again, the most obvious neutral candidate would be the Foundation.
I am opposed to
On Sun, Dec 8, 2013 at 12:40 PM, Drak wrote:
> Let me clarify. SSL renders BGP redirection useless because the browser
> holds the signatures of CA's it trusts: an attacker cannot spoof a
> certificate because it needs to be signed by a trusted CA: that's the point
> of SSL, it encrypts and proves
On Sun, Dec 8, 2013 at 12:51 PM, Drak wrote:
> What do you suggest though? We will need to trust someone (even in a group
> each person can act autonomously).
> The only thing I can suggest would be to hand the keys to the bitcoin
> project lead.
>
> Otherwise, who has admin rights to the code pro
On Sun, Dec 8, 2013 at 1:07 PM, Drak wrote:
> Simple verification relies on being able to answer the email sent to the
> person in the whois records, or standard admin/webmaster@ addresses to prove
> ownership of the domain
Godaddy and many other CA's are verified from nothing other than a
http f
On Mon, Dec 9, 2013 at 6:55 AM, Drak wrote:
> It was released and it's all over bitcointalk/reddit
It has not been released. It's queued for announcement. We were
waiting for another independant gitian build before sending out the
announcement.
---
On Mon, Dec 9, 2013 at 7:19 AM, Drak wrote:
> Why would it be made available for download at sourceforge.net if it's not
> actually released? The files are available here:
Because it takes time to put the files up, propagate to mirrors, check
by multiple people that the downloads work an the sign
On Mon, Dec 16, 2013 at 3:37 AM, Wladimir wrote:
> What we should really do is:
> - Use deterministic wallets. Making regular backups becomes optional (to
> retain label and transaction data and such) instead of mandatory.
> - Don't support importing private keys. Replace the importing of private
On Tue, Dec 17, 2013 at 2:41 PM, Troy Benjegerdes wrote:
> I want to get some feedback.. I've used distributed version control
> systems for a long time, and the most useful feature is to be able
> to merge two different forks.
We already automatically merge forks that we become aware of simply b
On Thu, Dec 19, 2013 at 5:47 PM, Mark Friedenbach wrote:
> Hello fellow bitcoin developers. Included below is the first draft of
> a BIP for a new Merkle-compressed data structure. The need for this
> data structure arose out of the misnamed "Ultimate blockchain
> compression" project, but it has
On Tue, Dec 31, 2013 at 5:39 AM, Drak wrote:
> The NSA has the ability, right now to change every download of bitcoin-qt,
> on the fly and the only cure is encryption.
Please cut it out with the snake oil pedaling. This is really over the
top. You're invoking the NSA as the threat here? Okay. The
On Tue, Dec 31, 2013 at 5:59 AM, Mike Hearn wrote:
> but moving to different ones is
> controversial, hence no progress :)
The site was actually moved onto a dedicated server temporarily and it
melted down under the load. I wouldn't call that no progress.
Perhaps I wasn't clear on the point I w
On Thu, Jan 2, 2014 at 9:22 PM, Troy Benjegerdes wrote:
> I believe this is self-explainatory:
>
> 1) Bitcoin usually runs on port 8333. Why?
>
> 2) Bitcoin does not show in up
> http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
> .. why?
>
> 3) What nee
On Fri, Jan 3, 2014 at 10:00 AM, Nadav Ivgi wrote:
> I had an idea for a payment scheme that uses key derivation, but instead of
> the payee deriving the addresses, the payer would do it.
>
> It would work like that:
>
> The payee publishes his master public key
> The payer generates a random "rec
On Sun, Jan 12, 2014 at 1:18 PM, Gavin Andresen wrote:
> No, please. Make it easy for non-geeks, extend the payment protocol, or
> we'll spend the next two years writing code that tries to ignore linebreaks
> and spaces and changing elements in HTML forms to
However, if you're able to use
On Mon, Jan 13, 2014 at 11:59 AM, Alan Reiner wrote:
> Then when someone
> wants to pay you, you simply give them the multiplier and root key (they
> already have the root key, but should verify).
[...]
> What
> advantages does "stealth addresses" have over this scheme? You could extend
> it usin
On Mon, Jan 13, 2014 at 12:41 PM, Alan Reiner wrote:
> It's not public. When I say "please pay me" I also say "use this
> multiplier". The multiplier isn't published, and it's not publicly
> discoverable without my wallet (or access to my email).
If you have enough of a communications channel t
On Wed, Jan 15, 2014 at 12:22 PM, Ben Davenport wrote:
> But may I suggest we consider changing the name "stealth address" to
> something more neutral?
ACK. Regardless of the 'political' overtones, I think stealth is a
little cringe-worthy.
"Private address" would be fine if not for confusion w
On Wed, Jan 15, 2014 at 4:05 PM, Jeremy Spilman wrote:
> Might I propose "reusable address".
I like this too.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyL
One challenge with reusable addresses is that while they result in a
small constant overhead for full nodes in searching for their own
transactions they create large overheads for SPV nodes.
One way to address this is for the SPV nodes to hand their servers
their blinding private key so that the s
On Wed, Jan 15, 2014 at 5:02 PM, Jeremy Spilman wrote:
> Choosing how many bits to put in the prefix may be difficult, particularly
> if transaction load changes dramatically over time. 0 or 1 bits may be
> just fine for a single user running their own node, whereas a central
> service might want
On Fri, Jan 17, 2014 at 8:55 PM, Alan Reiner wrote:
> Isn't there a much faster asymmetric scheme that we can use? I've heard
> people talk about ed25519, though I'm not sure it can be used for encryption.
Doing ECDH with our curve is within a factor of ~2 of the fastest
encryption available at
On Sat, Jan 18, 2014 at 3:12 PM, Jeremy Spilman wrote:
> In the case where payment is being sent only to Q1, and Q2 is for discovery
> only, perhaps we could use a 160-bit curve for d2/Q2 and e/P resulting in 20
> byte vs 32 bytes in the OP_RETURN, and of course faster multiplication.
>
> 80-bit
On Mon, Feb 10, 2014 at 3:28 AM, Drak wrote:
> What is the official response from the Bitcoin Core developers about MtGox's
> assertion that their problems are due to a fault of bitcoin, as opposed to a
> fault of their own?
>
> The technical analysis preluding this mess, was that MtGox was at fau
On Mon, Feb 10, 2014 at 8:30 AM, Troy Benjegerdes wrote:
> Name me one single person with commit access to the bitcoin github repository
> who is *independent* of any venture capital or other 'investment' connections.
I am, unless you count the fact that I own some Bitcoin and some
mining hardwar
On Mon, Feb 10, 2014 at 11:47 AM, Oliver Egginger wrote:
> As I understand this attack someone renames the transaction ID before
> being confirmed in the blockchain. Not easy but if he is fast enough it
> should be possible. With a bit of luck for the attacker the new
> transaction is added to the
On Mon, Feb 10, 2014 at 12:47 PM, Tier Nolan wrote:
> If the attacker has a direct connection to MtGox, they can receive the
> transaction directly.
MtGox had a php script that returned base64 data for all their stalled
transactions.
Not just attackers used that, some people trying to unstick the
On Tue, Feb 11, 2014 at 12:42 PM, naman naman wrote:
> I was talking about a DOS attack in
> https://bitcointalk.org/index.php?topic=458608.0 (ofcourse only applicable
> to entitys doing the tracking with txids).
>
> Amazing how I did not get a response from any of the devs (except Greg's
> respon
On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen wrote:
> Instead of trying to remove the possibility of transaction
> malleability, would it make sense to define a new, "canonical
> transaction hash/ID" (cTxID), which would be a hash of the part of the
> transaction data which we know is not m
On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos wrote:
> I apologize if this has been discussed many times before.
It has been, but there are probably many people like you who have not
bothered researching who may also be curious.
> As a long term solution to malleable transactions, wouldn't it be
On Wed, Feb 19, 2014 at 12:28 PM, Michael Gronager wrote:
> Twisting your words a bit I read:
>
> * you want to support relay of transactions that can be changed on the fly,
> but you consider it wrong to modify them.
> * #3 is already not forwarded, but you still find it relevant to support it.
dOn Wed, Feb 19, 2014 at 12:49 PM, Peter Todd wrote:
> While we might be able to get away with a retroactive change in meaning right
> now in the future that won't be so easy. There are lots if proposed
> applications for nLockTime-using protocols that depend on transactions (or
> parts of tran
On Thu, Feb 20, 2014 at 6:08 AM, Mike Hearn wrote:
> We've done forking changes before much faster than a year and that was with
> less experience. If we want, we can get this done within months.
You mean P2SH... which your implementation has only picked up support
for in the last month or so?
-
On Thu, Feb 20, 2014 at 6:29 AM, Gavin Andresen wrote:
> I think we should get Pieter's proposal done and implemented quickly. I
> agree with Mike, it doesn't have to take a long time for the core network to
> fully support this.
>
> Getting wallets to start generating transaction.version=3 might
On Thu, Feb 20, 2014 at 7:11 AM, Pieter Wuille wrote:
> I hereby request a BIP number.
62 assigned.
--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pit
On Thu, Feb 20, 2014 at 10:07 PM, Mike Hearn wrote:
> No, I was thinking of the height in coinbase change. At any rate, p2sh was
> supported by the consensus code in bitcoinj for a long time already, since
> it was first written.
>
> Support for sending to such addresses in the wallet appeared onc
On Mon, Feb 24, 2014 at 3:06 PM, Andreas Petersson wrote:
> Regarding 80 bytes vs smaller: The objectives should be that if you are
> determined to put some extra data in the blockchain, OP_RETURN should be
> the superior alternative. if a user can include more data with less fees
> using a multis
On Wed, Mar 5, 2014 at 11:39 AM, Peter Todd wrote:
> If you're following good practices you're not particularly vulneable to
> it, if at all, even if you make use of shared hosting. First of all you
> shouldn't be re-using addresses, which means you won't be passing that
> ~200 sig threshold.
>
>
On Wed, Mar 5, 2014 at 12:32 PM, Peter Todd wrote:
> That's nice, but I wrote my advice to show people how even if they don't
> know any crypto beyond what the "black boxes" do - the absolute minimum
> you need to know to write any Bitcoin software - you can still defend
> yourself against that at
On Wed, Mar 5, 2014 at 1:31 PM, Eric Lombrozo wrote:
> If we don't mind sacrificing some performance when signing, there's a fairly
> simple way to implement a constant-time constant-cache-access-pattern
> secp256k1.
> It is based on the idea of branchless implementations of the field and group
>
On Wed, Mar 5, 2014 at 2:14 PM, Eric Lombrozo wrote:
> Everything you say is true.
>
> However, branchless does reduce the attack surface considerably - if nothing
> else, it significantly ups the difficulty of an attack for a relatively low
> cost in program complexity, and that might still mak
On Wed, Mar 5, 2014 at 2:17 PM, Kevin wrote:
> Hello. How would I submit a patch? Could it be sent through the list
> as an attachment?
To the reference software? Normally you'd open a github account and
submit there.
Though if for some reason you can't— though its strongly preferred—
sending
On Sat, Mar 8, 2014 at 12:59 PM, Tom Geller wrote:
> Just an FYI: The Bitcoin wiki (https://en.bitcoin.it) is down.
>
> Is there a communication procedure or point person for such things?
This works. The wiki is in the process of changing control/operation.
Nothing to fear.
On Sat, Mar 8, 2014 at 11:34 AM, Luke-Jr wrote:
> On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote:
>> How can we patch this issue?
> No need, it is not an issue for Bitcoin.
> Properly used, there is only ever one signature per public key.
Security shouldn't depend on perfect use. There are
On Sun, Mar 16, 2014 at 6:24 AM, Thomas Voegtlin wrote:
>The encryption algorithm is ECIES, and code was was borrowed from
>https://github.com/jackjack-jj/jeeq. In order to know the public
>key corresponding to a Bitcoin address in your wallet, you can use
>the 'getpubkeys' comman
On Sun, Mar 16, 2014 at 7:31 AM, Thomas Voegtlin wrote:
> thanks for your feedback!
>
> I was not aware that that implementation was flawed.
> I will see how I can fix that code and get back to you.
It also leaks on the order of 7 bits of data about the message per
message chunk. I'm also think
On Sun, Mar 16, 2014 at 3:58 PM, Adam Back wrote:
> 2. you move coins to the side-chain by spending them to a fancy script,
> which suspends them, and allows them to be reanimated by the production of
> an SPV proof of burn on the side-chain.
One point to note here is that the if the whole move a
On Tue, Mar 25, 2014 at 2:03 PM, Mark Friedenbach 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 su
On Sat, Mar 29, 2014 at 7:28 AM, Watson Ladd wrote:
> This is not the case: one can use MPC techniques to compute a
> signature from shares without reconstructing the private key. There is
> a paper on this for bitcoin, but I don't know where it is.
Practically speaking you cannot unless the tech
On Sat, Mar 29, 2014 at 10:38 AM, Matt Whitlock wrote:
> But can threshold ECDSA work with BIP32?
Yes.
>In other words, can a threshold ECDSA public key be generated from separate,
>precomputed private keys,
No.
> can it only be generated interactively?
Yes.
But see the first question. Basi
On Sat, Mar 29, 2014 at 12:59 PM, Justus Ranvier
wrote:
> What would make it easier is if there was a standard output type for
> sending the entire transaction to miner fees,
Hm. maybe it could be called a "return operator" or something like that? :)
> that would make even large
> transactions p
On Sat, Mar 29, 2014 at 1:20 PM, Justus Ranvier wrote:
> On 03/29/2014 08:05 PM, Gregory Maxwell wrote:
>> Use dust-b-gone and make it someone elses problem to get it relayed. :)
> That's a sub-optimal solution, as it introduces a third party. What if
> his server goes
On Tue, Apr 1, 2014 at 12:00 PM, Pieter Wuille 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 curren
On Tue, Apr 1, 2014 at 1:53 PM, Pieter Wuille wrote:
> In case there are no further objections (excluding from people who
> disagree with me), I'd like to request a BIP number for this. Any
> number is fine, I guess, as long as it's finite.
With ten people commenting on this proposal there are qu
On Fri, Apr 4, 2014 at 6:51 AM, Nikita Schmidt
wrote:
> Fair enough. Although I would have chosen the field order (p) simply
> because that's how all arithmetic already works in bitcoin. One field
> for everybody. It's also very close to 2^256, although still smaller
> than your maximum prime.
On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock wrote:
> On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote:
>> I still repeat my concern that any private key secret sharing scheme
>> really ought to be compatible with threshold ECDSA, otherwise we're
>> just going
On Fri, Apr 4, 2014 at 9:36 AM, Matt Whitlock wrote:
> Are you proposing to switch from prime fields to a binary field? Because if
> you're going to "break up" a secret into little pieces, you can't assume that
> every piece of the secret will be strictly less than some 8-bit prime
> modulus. A
On Fri, Apr 4, 2014 at 10:16 AM, Matt Whitlock wrote:
> Honestly, that sounds a lot more complicated than what I have now. I made my
> current implementation because I just wanted something simple that would let
> me divide a private key into shares for purposes of dissemination to my next
> of
On Thu, Apr 3, 2014 at 8:41 PM, kjj wrote:
> At first, I thought this was a second April Fool's joke, but then I
> looked and saw that all of the BIPs really do use this format. As far
> as I can tell, we are using this insane format because RFC 822 predates
> ISO 8601 by half a decade.
In my op
On Sun, Apr 6, 2014 at 12:35 AM, Maciej Trebacz wrote:
> 00 01 | none | Proof of burn transaction. Use it if you want to effectively
> destroy coins (by sending it all as fees to miners)
For just having a dummy output for an all fee transaction you do not
need to have a PUSH at all.
On Mon, Apr 7, 2014 at 4:34 AM, Mike Hearn wrote:
> At the start of February we had 10,000 bitcoin nodes. Now we have 8,500 and
> still falling:
FWIW, A few months before that we had even less than 8500 by the bitnodes count.
Bitcoin.org recommends people away from running Bitcoin-QT now, so I'm
On Mon, Apr 7, 2014 at 6:50 AM, Gregory Maxwell wrote:
> FWIW, A few months before that we had even less than 8500 by the bitnodes
> count.
Gah, accidentally send I wanted to continue here that it was less
than 8500 and had been falling pretty consistently for months,
basically sin
On Mon, Apr 7, 2014 at 6:58 AM, Jameson Lopp wrote:
> The Bitnodes project updated their counting algorithm a month or so ago. It
> used to be slower and less accurate - prior to their update, it was reporting
> in excess of 100,000 nodes.
Nah. It reported multiple metrics. The "100,000" numbe
On Mon, Apr 7, 2014 at 8:45 AM, Justus Ranvier wrote:
> 1. The resource requirements of a full node are moving beyond the
> capabilities of casual users. This isn't inherently a problem - after
> all most people don't grow their own food, tailor their own clothes, or
> keep blacksmith tools handy
On Mon, Apr 7, 2014 at 9:27 AM, Mark Friedenbach wrote:
> Right now running a full-node on my home DSL connection (<1Mbps) makes
> other internet activity periodically unresponsive. I think we've already
> hit a point where resource requirements are pushing out casual users,
> although of course w
On Mon, Apr 7, 2014 at 10:01 AM, Mark Friedenbach wrote:
> On 04/07/2014 09:57 AM, Gregory Maxwell wrote:
>> That is an implementation issue— mostly one that arises as an indirect
>> consequence of not having headers first and the parallel fetch, not a
>> requirements issu
On Mon, Apr 7, 2014 at 10:40 AM, Mike Hearn wrote:
> Actually, I wonder
The actual validation isn't really the problem today. The slowness of
the IBD is almost exclusively the lack of parallel fetching and the
existence of slow peers. And making the signature gate adaptive (and
deploying the 6x
On Mon, Apr 7, 2014 at 11:35 AM, Tamas Blummer wrote:
> BTW, did we already agree on the service bits for an archive node?
I'm still very concerned that a binary archive bit will cause extreme
load hot-spotting and the kind of binary "Use lots of resources YES or
NO" I think we're currently suffe
On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer wrote:
> Once a single transaction in pruned in a block, the block is no longer
> eligible to be served to other nodes.
> Which transactions are pruned can be rather custom e.g. even depending on
> the wallet(s) of the node,
> therefore I guess it is
On Mon, Apr 7, 2014 at 12:00 PM, Tamas Blummer wrote:
> therefore I guess it is more handy to return some bitmap of pruned/full
> blocks than ranges.
A bitmap also means high overhead and— if it's used to advertise
non-contiguous blocks— poor locality, since blocks are fetched
sequentially.
On Mon, Apr 7, 2014 at 2:48 PM, Tier Nolan wrote:
>> Blocks can be loaded in random order once you have their order given by
>> the headers.
>> Computing the UTXO however will force you to at least temporarily store
>> the blocks unless you have plenty of RAM.
> You only need to store the UTXO set
On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
wrote:
> Regarding the choice of fields, any implementation of this BIP will
> need big integer arithmetic to do base-58 anyway.
Nah, it doesn't. E.g.
https://gitorious.org/bitcoin/libblkmaker/source/eb33f9c8e441ffef457a79d76ceed1ea20ab3059:base58.c
On Mon, Apr 7, 2014 at 6:46 PM, Matt Whitlock wrote:
> On Monday, 7 April 2014, at 5:38 pm, Gregory Maxwell wrote:
>> On Mon, Apr 7, 2014 at 5:33 PM, Nikita Schmidt
>> wrote:
>> > Regarding the choice of fields, any implementation of this BIP will
>> > need big
On Tue, Apr 8, 2014 at 9:13 AM, Angel Leon wrote:
> a home router that crashes or slows down when its NAT pin-hole table
> overflows, triggered by many TCP connections.
We don't form or need to form a great many connections.
> a home router that crashes or slows down by UDP traffic
We don't use
On Wed, Apr 9, 2014 at 8:42 AM, Brian Hoffman wrote:
> How would this affect the user in terms of disk storage? They're going to
> get hammered on space constraints aren't they? If it's not required how
> likely are users to enable this?
If Bitcoin core activates pruning a full node can be suppor
On Wed, Apr 9, 2014 at 8:41 AM, Natanael wrote:
> This could probably be done fairly easily by bundling Stratum (it's
> not just for pools!) and allowing SPV wallets to ask Bitcoind to start
> it (if you don't use it, there's no need to waste the resources), and
> then connect to it. The point of
On Wed, Apr 9, 2014 at 11:35 AM, Justus Ranvier wrote:
> If the security of the network depends on a broken incentive model,
> then fix the design of the network so that economics works for you
> instead of against you.
Who says anything about a broken incentive model. You've made past
claims abo
On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier wrote:
> Anyone reading the archives of the list will see about triple the
> number of people independently confirming the resource usage problem
> than they will see denying it, so I'm not particularly worried.
The list has open membership, there i
On Wed, Apr 9, 2014 at 1:36 PM, Mark Friedenbach wrote:
> (2) there's a reasonable pathway to doing this all in-protocol, so there's
> no reason to introduce external dependencies.
Not just a speculative pathway. Pieter implemented headers first:
https://github.com/sipa/bitcoin/tree/headersfirst
On Thu, Apr 10, 2014 at 4:32 AM, Pieter Wuille wrote:
> There were earlier discussions.
On this list.
> The two ideas were either using one or a few service bits to indicate
> availability of blocks, or to extend addr messages with some flags to
> indicate this information.
>
> I wonder whether
On Thu, Apr 10, 2014 at 4:57 AM, Wladimir wrote:
> Just wondering: Would there be a use for a [static] node that, say, always
> serves only the first 10 blocks? Or, even, a static range like block
> 10 - 20?
The last time we discussed this sipa collected data based on how often
blocks
On Thu, Apr 10, 2014 at 3:24 PM, Jesus Cea wrote:
> On 11/04/14 00:15, Mark Friedenbach wrote:
>> Checkpoints will go away, eventually.
> Why?. The points in the forum thread seem pretty sensible.
Because with headers first synchronization the major problems that
they solve— e.g. block flooding D
On Thu, Apr 10, 2014 at 10:30 AM, Tier Nolan wrote:
> Error correction is an interesting suggestion.
Though I mentioned it, it was in jest— I think right now it would be
an over-design at least for the basic protocol. Also, storing
'random' blocks has some locality problems, when verifying block
Bringing the thread back on-topic:
On Wed, Apr 16, 2014 at 1:14 AM, Wladimir wrote:
> Hello,
> Today I noticed that even my bank is warning people to not do internet
> banking with Windows XP.
> If it is no longer secure enough for online banking it's CERTAINLY not
> secure enough to run a wallet
On Tue, Apr 22, 2014 at 1:06 AM, Jan Møller wrote:
> This is a very useful BIP, and I am very much looking forward to
> implementing it in Mycelium, in particular for bip32 wallets.
I haven't seen commentary from you on the Kogelman draft, it would be
helpful there: https://bitcointalk.org/index.
On Tue, Apr 22, 2014 at 11:29 AM, Tamas Blummer wrote:
> Yes, it is current norm. I am questioning if we should hang on to it in
> BIPs.
>
> I see testnet as a tool for a certain type of testing. Its existence is
> likely a consequence of Satoshi not writing unit tests and having automated
> integ
On Tue, Apr 22, 2014 at 10:33 PM, Tamas Blummer wrote:
> So you agree, that SSS should not contain specific flag for testnet?
>
> Or for that matter not even BIP32 needs them since it is not an address to
> send to.
I think the convention we have so far is that addresses and address
relate thing
On Wed, Apr 23, 2014 at 12:55 AM, Mike Hearn wrote:
> Lately someone launched Finney attacks as a service (BitUndo). As a reminder
> for newcomers, Finney attacks are where a miner secretly works on a block
> containing a double spend.
Hm? I didn't think this is at all what they did. What they c
On Wed, Apr 23, 2014 at 12:19 PM, Mike Hearn wrote:
> That's the definition of a Finney attack, right?
A finney attack is where you attempt to mine a block with a
transaction paying you, and as soon as you are successful you quickly
make a transaction spending that coin to someone else, then rele
On Wed, Apr 23, 2014 at 12:59 PM, Mike Hearn wrote:
>> What you're talking about is just disagreement about the content of
>> the memory pool
> That's the same thing. Whilst you're mining your double spend tx, it's in
> your mempool but you don't broadcast it as per normal. Then when you find
> th
On Wed, Apr 23, 2014 at 1:44 PM, Adam Ritter wrote:
> Isn't a faster blockchain for transactions (maybe as a sidechain) solving
> the problem? If there would be a safe way for 0-confirmation transactions,
> the Bitcoin blockchain wouldn't even be needed.
Large scale consensus can't generally prov
301 - 400 of 454 matches
Mail list logo
