On Thu, Jun 18, 2015 at 7:24 PM, Matt Corallo wrote:
> Ive been trying to stay out of these increasingly useless shit-throwing
> contests, but I wanted to take objection to this... I highly, highly doubt
> any seriously technical person is making any kind of decision on block size
> issues base
On Thu, Jun 18, 2015 at 1:36 PM, Mike Hearn wrote:
>> And allegations that the project is "run like wikipedia" or "an edit war"
>> are verifyably untrue.
>> Check the commit history.
>
> This was a reference to a post by Gregory on Reddit where he said if Gavin
> were to do a pull request for the
On Wed, Jun 17, 2015 at 1:00 AM, Mark Friedenbach wrote:
> Given that we have had more than two weeks of public discussion, code is
> available and reviewed, and several community identified issues resolved, I
> would like to formally request a BIP number be assigned for this work. Will
> the BIP
Is there any discussion thats been had relating to the BIP-drafts at:
https://github.com/Open-Transactions/rfc/tree/master/bips
Fellow Traveler has apparently been waiting 9 months for progress on
these proposals and I'm trying to find out where the breakdown
happened. While do not doubt that I a
On Mon, Jun 15, 2015 at 2:29 AM, Rusty Russell wrote:
> The softfork argument I find the most compelling, though it's tempting
> to argue that every ordering use (including SIGHASH_SINGLE) is likely
> a mistake.
Oh.
Hm.
It is the case that the generalized sighash flag design I was thinking
abou
On Mon, Jun 8, 2015 at 9:25 PM, Danny Thorpe wrote:
> Recommending sorting of the inputs and outputs as a best practice is fine
> (and better than random, IMO), but not as part of IsStandard() or consensus
> rules. There are cases where the order of the inputs and outputs is
> significant.
Is it
On Sat, Jun 6, 2015 at 4:42 AM, Rusty Russell wrote:
> Title: Canonical Input and Output Ordering
> Author: Rusty Russell
> Discussions-To: "Bitcoin Dev"
> Status: Draft
> Type: Standards Track
> Created: 2015-06-06
>
> Abstract
>
> This BIP provides a canonical ordering of inputs and outputs wh
On Sun, Jun 14, 2015 at 10:12 AM, Warren Togami Jr. wrote:
> From the perspective of our community, for bitcoin-dev it seems like a great
> fit. Why? While they are interested in supporting general open source
> development, the LF has literally zero stake in this. In addition to
> neutrality,
On Wed, May 27, 2015 at 9:59 PM, Mike Hearn wrote:
> I wrote an article that explains the hashing assurance contract concept:
>
> https://medium.com/@octskyward/hashing-7d04a887acc8
>
> (it doesn't contain an in depth protocol description)
The prior (and seemingly this) assurance contract proposa
On Wed, May 27, 2015 at 7:47 AM, Peter Todd wrote:
> Equally this proposal is no more "consensus enforcement" than simply
> increasing the fee (and possibly decreasing the absolute nLockTime) for
You've misunderstood it, I think-- Functionally nlocktime but relative
to each txin's height.
But th
On Tue, May 26, 2015 at 11:00 PM, Tom Harding wrote:
> The bitcoin transaction is part of a real-world "deal" with unknown
> connections to the other parts
I'm having a hard time parsing this. You might as well say that its
part of a weeblix for how informative it is, since you've not defined
it
On Tue, May 26, 2015 at 5:54 PM, Tom Harding wrote:
> It's not difficult to
> imagine real-world consequences to not having contributed to the
> transaction.
I'm having a hard time. Can you help me understand a specific case
where this makes a difference.
It appears to be a gratuitous requireme
On Tue, May 12, 2015 at 8:10 PM, Jeff Garzik wrote:
> True. Part of the issue rests on the block sync horizon/cliff. There is a
> value X which is the average number of blocks the 90th percentile of nodes
> need in order to sync. It is sufficient for the [semi-]pruned nodes to keep
> X blocks,
On Tue, May 12, 2015 at 7:38 PM, Jeff Garzik wrote:
> One general problem is that security is weakened when an attacker can DoS a
> small part of the chain by DoS'ing a small number of nodes - yet the impact
> is a network-wide DoS because nobody can complete a sync.
It might be more interesting
It's a little frustrating to see this just repeated without even
paying attention to the desirable characteristics from the prior
discussions.
Summarizing from memory:
(0) Block coverage should have locality; historical blocks are
(almost) always needed in contiguous ranges. Having random peers
On Sun, May 10, 2015 at 9:21 PM, Gavin Andresen wrote:
> a while I think any algorithm that ties difficulty to block size is just a
> complicated way of dictating minimum fees.
Thats not the long term effect or the motivation-- what you're seeing
is that the subsidy gets in the way here. Conside
On Sun, May 10, 2015 at 8:45 PM, Sergio Lerner
wrote:
> Can the system by gamed?
Users can pay fees or a portion of fees out of band to miner(s); this
is undetectable to the network.
It's also behavior that miners have engaged in since at least 2011 (in
two forms; treating transactions that pai
On Fri, May 8, 2015 at 8:33 PM, Mark Friedenbach wrote:
> These rules create an incentive environment where raising the block size has
> a real cost associated with it: a more difficult hashcash target for the
> same subsidy reward. For rational miners that cost must be counter-balanced
> by addit
On Sat, May 9, 2015 at 12:00 AM, Damian Gomez wrote:
>
> ...of the following:
>
> the DH_GENERATION would in effect calculate the reponses for a total
> overage of the public component, by addding a ternary option in the actual
> DH key (which I have attached to sse if you can iunderstand my logi
On Wed, May 6, 2015 at 10:12 PM, Matt Corallo
wrote: > Recently there has been a flurry of posts by Gavin at >
http://gavinandresen.svbtle.com/ which advocate strongly for increasing >
the maximum block size. However, there hasnt been any discussion on this >
mailing list in several years as far a
On Fri, Apr 24, 2015 at 8:00 PM, Justus Ranvier
wrote:
> https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki
>
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
>
> Payment codes are SPV-friendly alternatives to DarkWallet-style stea
On Fri, Apr 24, 2015 at 7:58 PM, William Swanson wrote:
> On Thu, Apr 16, 2015 at 9:12 AM, s7r wrote:
>> Thanks for your reply. I agree. Allen has a good point in the previous
>> email too, so the suggestion might not fix anything and complicate things.
>
> The BIP 62 approach to malleability isn
On Wed, Apr 8, 2015 at 7:50 PM, Stephen Morse
wrote:
> Seeking feedback on a proposal that will allow a transaction signer to
> explicitly specify what is to be serialized for the signature hash. The
> basic idea is to make the nHashType general enough that we won't need a new
> sighash flag every
On Tue, Apr 7, 2015 at 9:32 PM, Jean-Paul Kogelman
wrote:
> https://eprint.iacr.org/2015/310.pdf
http://www.reddit.com/r/Bitcoin/comments/31rcuo/new_algorithm_for_the_discrete_logarithm_problem/cq4b52u
--
BPM Camp - Free
On Fri, Mar 27, 2015 at 1:51 AM, Thy Shizzle wrote:
> Yes I agree, also there is talks about a government body I know of warming
> to bitcoin by issuing addresses for use by a business and then all
> transactions can be tracked for that business entity. This is one proposal I
> saw put forward by
On Thu, Mar 26, 2015 at 10:28 PM, s7r wrote:
> This should not be enforced by default.
No one suggested _anything_ like that. Please save the concern for
someplace its actually applicable.
> I know it's not recommended to use the same pubkey more than once, but
> the protocol was not designed th
On Thu, Mar 26, 2015 at 9:26 PM, Tom Harding wrote:
> I should have been clearer that the motivation for address expiration is to
> reduce the rate of increase of the massive pile of bitcoin addresses out
> there which have to be monitored forever for future payments. It could make
> a significan
On Thu, Mar 26, 2015 at 8:38 PM, Tom Harding wrote:
> I addressed that by limiting the duplicate check to an X-block segment. X
> is hard-coded in this simple scheme (X=144 => "1-day addresses"). You
> could picture a selectable expiration duration too.
If its to be heuristic in any case why n
On Wed, Mar 25, 2015 at 6:44 PM, Tom Harding wrote:
> Is this assuming payment protocol? A major benefit of address
> expiration, if it works, would be that it works without requiring
> payment protocol.
Not at all.
> Are you suggesting there is no implementation of address expiration that
> wo
On Wed, Mar 25, 2015 at 1:57 AM, Tom Harding wrote:
> The idea of limited-lifetime addresses was discussed on 2014-07-15 in
>
> http://thread.gmane.org/gmane.comp.bitcoin.devel/5837
>
> It appears that a limited-lifetime address, such as the fanciful
>
> address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36
This seems overly complicated to me, unless I'm missing something.
Instead, I think you should just give the server the master pubkey P
only without the chaincode.
Then when you transact you generate the address in whatever manner you
like and tell the server the scalar value iL which the user c
On Thu, Mar 12, 2015 at 2:41 AM, devrandom wrote:
> I think there are some important advantages to not being forced to use
> the old wallet to send coins when switching wallets. The three I can
> think of right now are: maintaining transaction history,
Just loading a key doesn't keep transaction
On Wed, Mar 11, 2015 at 11:50 PM, devrandom wrote:
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling.
The fact remains that there are several apparently unresolvable
well-principled perspec
On Wed, Mar 11, 2015 at 11:24 PM, Pindar Wong wrote:
> Perhaps at some point consider introducing something akin to a
> 'Bitcoin-Draft' (BD) status with some autoexpiry period?
>
> I understand that the Internet Engineering Task Force (IETF) has the
> concept of 'Internet Drafts" (ID) and this lo
On Wed, Mar 11, 2015 at 11:45 AM, Thomas Kerin wrote:
> I used BIP0090 as a place-holder, but I would like to request a BIP number
> for this now.
We have had repeated problems in the past with people working on and
circulating prior draft proposals squatting on each others numbers,
and each dema
On Wed, Mar 11, 2015 at 7:24 PM, Ricardo Filipe
wrote:
> i guess you look at the glass half full :)
> even though what you say is true, we should aim for wallets not to
> require those instructions, by standardizing these things in BIPs.
> let's hope bitcoin doesn't fail in standards as our indust
It would appear that the Bitcoin Foundation has decided that their
next two seats would be decided by miners. (More information
available at:
https://bitcoinfoundation.org/forum/index.php?/topic/1255-blockchain-voting/#entry13453
)
Unfortunately, they seem to have not provided the software need
On Fri, Feb 20, 2015 at 5:59 PM, Adam Back wrote:
> So now they ask a full node for merkle paths + transactions for the
> addresses from the UTXO set from the block(s) that it was found in.
Use of the words "UTXO set" here is probably confusing people as it's
likely to make people think of the co
On Fri, Feb 20, 2015 at 4:54 PM, Mike Hearn wrote:
> And then what? So you know the block matches. But with reasonable FP rates
> every block will match at least a few transactions (this is already the case
This approach needs a filter set with a lower FP rate. It doesn't
depend on having a high
On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn wrote:
> history. Lots of miners have dropped out due to hardware obsolescence, yet
> massive double spending hasn't happened.
How many thousands of BTC must be stolen by miners before you'd agree
that it has, in fact, happened?
(https://bitcointalk.org
On Wed, Feb 4, 2015 at 2:23 PM, Isidor Zeuner
wrote:
> Hi there,
>
> traditionally, the Bitcoin client strives to hide which output
> addresses are change addresses going back to the payer. However,
> especially with today's dynamically calculated miner fees, this
> may often be ineffective:
>
> A
On Tue, Feb 3, 2015 at 12:44 AM, Pieter Wuille wrote:
> The much simpler alternative is just adding this to BIP66's DERSIG
> right now, which is a one-line change that's obviously softforking. Is
> anyone opposed to doing so at this stage?
Thats my preference.
---
On Sun, Feb 1, 2015 at 8:08 PM, xor wrote:
> Why is that?
Because Binaries on Bitcoin.org have always been unaffected by the
issue 0.9.4 was released to address.
> Also, is it correct that there wasn't a release candidate before the release?
> Sounds dangerous to me.
The changes were tried firs
On Mon, Jan 26, 2015 at 5:14 AM, Pieter Wuille wrote:
> On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille
> wrote:
>> I therefore propose a softfork to make non-DER signatures illegal
>> (they've been non-standard since v0.8.0). A draft BIP text can be
>> found on:
>>
>> https://gist.github.com
On Sun, Jan 25, 2015 at 2:34 PM, Pieter Wuille wrote:
> * Add it to the softfork now, and be done with it.
Initially I was of the opinion that we couldn't do that, because
soft-forks which hit transactions many nodes would relay+mine creates
a forking risk... but with the realization that imbalan
On Fri, Jan 23, 2015 at 5:40 PM, slush wrote:
> Yes, the step you're missing is "and build the table". Dynamic memory
> allocation is something you want to avoid, as well as any artifical
> restrictions to number of inputs or outputs. Current solution is slow, but
> there's really no limitation on
On Fri, Jan 23, 2015 at 4:18 PM, slush wrote:
> Can you send me any reference about this? Of course if that solves the
> problem, hard fork would not be necessary anymore. I'm just not aware of
> any.
Sure; will aggregate up the citations when I'm not travling later today.
> To sign transaction
On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner wrote:
> Unfortunately, it seems that there was no soft-fork way to achieve this
> benefit, at least not one that had favorable properties. Most of the
> soft-fork variations of it required the coins being spent to have been
> originated in a special w
OpenSSL 1.0.0p / 1.0.1k was recently released and is being
pushed out by various operating system maintainers. My review
determined that this update is incompatible with the Bitcoin
system and could lead to consensus forks.
Bitcoin Core released binaries from Bitcoin.org are unaffected,
as are an
On Fri, Jan 9, 2015 at 1:42 PM, Mike Hearn wrote:
> Additionally, there is a school of thought that says Bitcoin must work even
> if lots of miners are malicious and willing to break arbitrary things in
> order to try and get more money. I don't think Bitcoin can really be a
This being unsafe doe
On Fri, Jan 9, 2015 at 1:20 PM, Mike Hearn wrote:
>> A limitation on most existing micropayment channel ideas is that payments
>> can only flow in one direction.
> It's worth noting that the original protocol as designed by Satoshi did not
> have this limitation. It has evolved this way because of
On Sun, Jan 4, 2015 at 6:11 PM, Ross Nicoll wrote:
> Ah, thanks for that.
>
> I'll try Peter's patch for testnet tomorrow, sounds like it should fix
> this for my use case.
Thanks for presenting your solution as code in any case. In spite of
the fact that I gave it a crappy read this time, it rea
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell wrote:
> Can you send me the actual raw transaction (that site doesn't appear
> have a way to get it, only some cooked json output; which doesn't
> include the sequence number).
Nevermind, I guess. I think I figured out your pro
On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll wrote:
> Grabbing a simple test case:
> https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
> - that won't lock until 0028 UTC on the 5th.
>
> I've tried closing the wallet, moving the wallet.dat file out of the
>
On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll wrote:
> Dear all,
>
> I've been looking at atomic cross-chain trading (
> https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
> Bitcoin and Dogecoin blockchains, and have a mostly functional
> prototype. However as it stands if the refun
On Tue, Dec 30, 2014 at 4:25 PM, Sergio Lerner
wrote:
> Slight off-topic:
> That looks like an abuse of the VM. Even P2SH is an abuse of the VM.
> Gavin's OP_EVAL (hard-fork) should had been chosen. I'm taking about a
> simple change that goes along the lines of Satoshi's original design.
> Bitcoi
On Mon, Dec 29, 2014 at 7:21 PM, Sergio Lerner
wrote:
> I propose to allow miners to voluntarily lock funds by letting miners
> add additional inputs to the coinbase transaction. Currently the
> coinbase transaction does not allow any real input to be added (only a
> pseudo-input).
> This is a ha
On Wed, Dec 24, 2014 at 5:08 PM, Will Bickford wrote:
> A tally from August indicated that I may need to slog through 280,000 lines
You're counting 170kloc of machine generated code with the translation
strings there.
The top level (/src) and libconsensus are only about 36kloc. This is
small eno
On Sat, Dec 20, 2014 at 11:14 AM, Jeremy Spilman wrote:
>> are dnsseeds being blocked
> ostensibly because they are acting as dyanamic DNS infrastructure for
> malware sites?
Pretty much appears to be the case. In every instance it appears to be
automated. This predates the msft no-ip.com stuff.
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd wrote:
[snip]
> Pull-req #4890², specifically commit c7829ea7, changed the
This change was authored more than three months ago and merged more
than two months ago.
[And also, AFAICT, prior to you authoring BIP65]
I didn't participate in that pull-req,
On Fri, Nov 28, 2014 at 11:45 AM, Flavien Charlon
wrote:
>> This breaks existing invariants and would make the coins potentially less
>> fungible because they wouldn't be reorg safe.
>
> I'm not sure coins are ever reorg safe. All it takes is a double spend in
> the history of your coins for them
On Fri, Nov 28, 2014 at 12:45 AM, Mistr Bigs wrote:
> That's what I was trying to say... The researchers are deanonymizing
> transactions from non-Tor connected hosts. So why are we talking about Tor
> limitations in response to this? Shouldn't we be discussing how to address
> the issues in Bitco
On Thu, Nov 27, 2014 at 10:56 PM, Richard Moore wrote:
> Heya,
>
> I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and
> thought it might make more sense to instead have a OP_CHECKLOCKTIME which
> would simply push an OP_TRUE or OP_FALSE onto the stack?
Updating the stack is no
On Thu, Nov 27, 2014 at 5:44 PM, Mistr Bigs wrote:
> I might be mistaken, but it seems to me this paper discusses unintended ways
> of obtaining the IP addresses of clients involved in transactions on the
> core Bitcoin network.
You're mistaken. :)
If a node is used exclusively via tor it effect
> Since this attack vector has been discussed, I started making some
> measurements on how effective it is to connect to Bitcoin using Tor,
> and I found that the number of connections dropping to near-zero is
> a situation which occurs rather frequently, which suggests that there
> is still room t
Some initial comments...
Tying in the protocol changes is really confusing and the fact that
they seem to be required out the gates would seemingly make this much
harder to deploy. Is there a need to do that? Why can't the p2p part
be entirely separate from the comitted data?
On Mon, Nov 10, 20
On Thu, Nov 6, 2014 at 11:12 PM, Peter Todd wrote:
> BIP62 does make life easier for wallet authors as they don't have to
> deal with malleability - maybe! -
Yes, I agree for most contract purposes CTLV is what you want to be
using, instead of refund transactions beyond being more clearly
correct
On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell wrote:
> Hi all,
>
> I've been toying with an algorithm to place a ceiling on
> confirmation latency by allowing weaker blocks after a certain time.
> Hope this isn't noise, but thought someone must have considered this
> before, or know of f
On Tue, Oct 28, 2014 at 9:19 PM, Jérémie Dubois-Lacoste
wrote:
> The fact that a topic was brought up many times since a long time,
> does not mean it is not relevant.
I am not saying that it is "not relevant", I'm saying the discussion
is pointless:
No new information has arrived since the very
On Tue, Oct 28, 2014 at 8:17 PM, Ferdinando M. Ametrano
wrote:
>
> On Oct 25, 2014 9:19 PM, "Gavin Andresen" wrote:
> > We had a halving, and it was a non-event.
> > Is there some reason to believe next time will be different?
>
> In november 2008 bitcoin was a much younger ecosystem,
Or very ol
On Tue, Oct 28, 2014 at 2:26 AM, Tom Harding wrote:
> Matt,
>
> You're right, thanks. Without double-spend relay, miner won't know that
> some txes conflict with anything.
Even with that, the miner cannot tell, his only safe option is to
include no transactions at all.
Consider a malicious mine
On Wed, Oct 15, 2014 at 8:29 AM, Wladimir wrote:
> Hello,
>
> I'm trying to create a bit of process around the
> https://github.com/bitcoin/bips repository.
>
> A) Currently a lot of pulls are open for various BIPs and it is not
> clear who should comment on them, or who decides on changes to be
>
On Tue, Oct 14, 2014 at 7:27 AM, Thomas Zander wrote:
> What about rejecting a script where a bool is not explicitly zero or one?
I believe this is what he actually meant.
--
Comprehensive Server Monitoring with Site24x7
On Tue, Oct 14, 2014 at 2:34 AM, Pieter Wuille wrote:
> Hi all,
>
> while working on a BIP62 implementation I discovered yet another type
> of malleability: the interpretation of booleans.
>
> Any byte array with non-zero bytes in it (ignoring the highest bit of
> the last byte, which is the sign
On Sat, Oct 11, 2014 at 11:34 PM, Pieter Wuille wrote:
> * Parallel block downloading (much faster sync on typical network
> connections).
"Much faster" is an understatement. Benchmarking here shows one hour
five minutes syncing to 295000. Old code isn't even at 25 after
7 hours.
(I'm us
On Thu, Oct 9, 2014 at 6:33 AM, Peter Todd wrote:
> Speaking of, can anyone think of an example of a complex transaction
> use-case that is affected by malleability which can't be fixed by
> CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
> trying to think of a good example.
On Thu, Oct 9, 2014 at 6:14 AM, Adam Back wrote:
> I think you can do everything with the existing script level nlocktime
> in some kind of turing completeness sense (maybe); but there is a
> complexity cost that often you have to resort to extra dependent
> transaction(s) (and work-around malleab
On Tue, Oct 7, 2014 at 7:04 PM, Sergio Lerner wrote:
> Using the my previous terminology, automatic fee-sharing ("ORBS") is a
> solution to the freeze problem ("FRONT") but opens the windows to
> "CHAKIDO" double-spending. and CHAKIDO double-spending is a much worse
> problem than FRONT.
I'm not
On Sun, Oct 5, 2014 at 4:54 PM, Jorge Timón wrote:
> 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.
You can imagine that instead of subsidy Bitcoin came with a initial
s
On Sun, Oct 5, 2014 at 4:40 PM, Gregory Maxwell
> I should point you to some of the tools that have been discussed in
> the past which are potentially helpful here:
Ah, I should also mention a somewhat more far out approach which helps
here as a side effect:
If transactions were using t
On Sun, Oct 5, 2014 at 4:00 PM, Sergio Lerner wrote:
> I would like to share with you a vulnerability in the Bitcoin protocol I've
> been thinking of which might have impact on the future of Bitcoin. Please
> criticize it!
> The Freeze on Transaction Problem
I should point you to some of the tool
On Fri, Oct 3, 2014 at 7:28 AM, Matt Whitlock wrote:
> Is there a reason why we can't have the new opcode simply replace the top
> stack item with the block height of the txout being redeemed?
This would not be soft-forking compatible.
It also would be unsafe in that it would result in transact
On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier wrote:
> Two draft information BIPs are attached.
I've pinged some people privately but also pinging the list… no
commentary on this proposal?
--
Meet PCI DSS 3.0 Complian
On Mon, Sep 15, 2014 at 3:51 PM, Matt Whitlock wrote:
> On Monday, 15 September 2014, at 5:10 pm, Thomas Zander wrote:
>> So for instance I start including a bitcoin public key in my email signature.
>> I don't sign the emails or anything like that, just to establish that
>> everyone
>> has my pu
On Fri, Jul 18, 2014 at 8:14 AM, Pieter Wuille wrote:
> Hi all,
>
> I've sent a pull request to make a small change to BIP 62 (my
> anti-malleability proposal) which is still a draft; see:
> * https://github.com/bitcoin/bips/pull/90 (the request)
> * https://github.com/sipa/bips/blob/bip62up/bip-0
On Tue, Aug 26, 2014 at 5:57 PM, Mem Wallet wrote:
>
> Does anyone see a value in a standardized PGP-style message,
> which would allow someone performing a bitcoin transaction to
> send signed encrypted messages using only public and private
> bitcoin keys ?
>
> I'd like to propose a signed encry
On Sat, Aug 23, 2014 at 1:36 PM, Paul Rabahy wrote:
> I want go give a bit of an outsiders perspective. I thoroughly understand
> the concepts of bitcoin and am a professional programmer, but have never
> taken the time to compile my own copy of bitcoin core.
>
> I have looked at the pull requests
On Tue, Aug 19, 2014 at 6:26 PM, Troy Benjegerdes wrote:
> If a project cannot be organized enough to run its own hosting/web presense/
> counterintelligence/security that starts with installing an OS and patching
> kernels, then it is really not wise for me to trust my financial future to
> softw
On Tue, Aug 19, 2014 at 4:39 PM, Justus Ranvier
wrote:
> While the rest of the 'net is busy deprecating HTTP and all other
> unencrypted transport methods, why is it(*) even a debate?
I think it's desirable (and you can go look in #bitcoin-dev logs for
me talking about it in the past)— but all of
On Tue, Aug 19, 2014 at 5:02 AM, Jeff Garzik wrote:
> It would be nice if the issues and git repo for Bitcoin Core were not
> on such a centralized service as github, nice and convenient as it is.
>
> To that end, I note that Linux does its own git repo, and now requires
> 2FA:
> http://www.linux
On Tue, Aug 19, 2014 at 9:07 AM, Justus Ranvier
wrote:
> If that's not acceptable, even using TLS with self-signed certificates
> would be an improvement.
TLS is a huge complex attack surface, any use of it requires an
additional dependency with a large amount of difficult to audit code.
TLS is t
On Mon, Aug 18, 2014 at 2:02 PM, Ivan Pustogarov wrote:
> For each neighbour, a Bitcoin peer keeps the history of addresses that
> it forwarded to the neighbour. If an address was already forwarded
> to a neighbour it is not retransmitted again.
Okay, sorry, I thought you were saying something el
On Mon, Aug 18, 2014 at 1:33 PM, Ivan Pustogarov wrote:
> The attack I'm trying to address is described here:
> https://www.cryptolux.org/index.php/Bitcoin
> It was discussed here: https://bitcointalk.org/index.php?topic=632124.0
>
> It uses the following observation. Each NATed client connects t
On Mon, Aug 18, 2014 at 11:37 AM, Ivan Pustogarov
wrote:
> the same for a long time, an attacker which does not have any peers at all
> but just listens the Bitcoin network can link together differed BC addresses
> and learn the IP of the client.
I don't understand what you're talking about here;
On Mon, Aug 18, 2014 at 10:30 AM, Pieter Wuille wrote:
> Yes, I believe peer rotation is useful, but not for privacy - just for
> improving the network's internal knowledge.
>
> I haven't looked at the implementation yet, but how I imagined it would be
> every X minutes you attempt a new outgoing
On Mon, Aug 18, 2014 at 9:46 AM, Ivan Pustogarov wrote:
> Hi there,
> I'd like to start a discussion on periodic rotation of outbound connections.
> E.g. every 2-10 minutes an outbound connections is dropped and replaced
> by a new one.
Connection rotation would be fine for improving a node's kno
On Thu, Jul 31, 2014 at 8:26 PM, Matt Whitlock wrote:
> I understand what you're saying, but I don't understand why it's a problem.
> Transactions shouldn't be considered "final" until a reasonable number of
> confirmations anyway, so the possibility that an "accepted" transaction could
> becom
On Thu, Jul 31, 2014 at 6:38 PM, Matt Whitlock wrote:
> It would make more sense to introduce a new script opcode that pushes the
> current block height onto the operand stack. Then you could implement
> arbitrary logic about which blocks the transaction can be valid in. This
> would require th
On Thu, Jul 31, 2014 at 3:27 PM, Kaz Wesley wrote:
>> the FEC still lets you fill in the missing transactions without knowing in
>> advance all that will be missing.
>
> I don't see why we need to solve that problem, since the protocol
> already involves exchanging the information necessary to de
On Thu, Jul 31, 2014 at 2:41 PM, Kaz Wesley wrote:
>> the need to have transmitted the transaction list [..] first
>
> 32 bits per transaction is at least double the communication overhead
> of the simple approach, and only offers a bound on the probability of
> needing a round trip.
"(e.g. from
1 - 100 of 454 matches
Mail list logo
