Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically, you cannot have it. Neither do you or anyone else. > There is protocol for how change is effected in a FOSS project. And it allows the minority to hold the majority hostage. > If you take the risks with Mike&GavCoin, that wou

Re: [Bitcoin-development] The Bitcoin Node Market

No,Bitcoin 发自我的 iPhone > 在 2015年6月16日，13:28，justusranv...@riseup.net 写道： > >> On 2015-06-16 03:49, Kevin Greene wrote: >> ​Hah, fair enough, there is no such thing as the "right" way to do >> anything. But I still think punishing users who use SPV wallets is ​a >> less-than-ideal way to incent

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

Mike Hearn, In the light of your responses to Adam Back's questions, below, I feel it is time to speak up because what I now understand, and is implied, is that Mike Hearn and Gavin Andresen have planned and deployed the infrastructure for a Bitcoin hard-fork and intend to action it despite majori

Re: [Bitcoin-development] The Bitcoin Node Market

On 2015-06-16 03:49, Kevin Greene wrote: > ​Hah, fair enough, there is no such thing as the "right" way to do > anything. But I still think punishing users who use SPV wallets is ​a > less-than-ideal way to incentive people to run full nodes. Right now > SPV is > the best way that exists for mobil

Re: [Bitcoin-development] BIP for Proof of Payment

Shared wallets were discussed earlier as a feature. If you pay a for dry cleaning with a shared wallet, a different 1-of-N signer can pick up the clothes with no physical transfer of a claim check, by proving the money that paid for the cleaning was his. Many kinds of vouchers can be eliminated,

Re: [Bitcoin-development] The Bitcoin Node Market

> Would SPV wallets have to pay to connect to the network too? The cost to compute and deliver the requested data will be pushed to the users of that node. This is the same way all costs, fees, and taxes of any business are always paid by its customers. The Bitcoin Network will not thrive in a de

Re: [Bitcoin-development] The Bitcoin Node Market

We're planning to run our own full nodes to take load off the volunteer network as breadwallet use increases, and also contribute any SPV serving performance optimizations we can make to bitcoin-core. Just want to let people know we share these concerns and have plans to mitigate any negative impac

Re: [Bitcoin-development] The Bitcoin Node Market

Just thinking off the top of my head here: What if SPV wallets were exempt from the fee? Only full nodes would pay other full nodes when initially sync'ing the blockchain. Then as long as you keep your full node running for a long period of time, you'll eventually make back the cost you paid to sy

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

Thanks Alex, the work you've pointed out is helpful. Limiting mempool size should at least prevent nodes from crashing. When I looked a few days ago I only found a few old PRs that seemed to have fallen by the wayside, so this new one is encouraging. I can respond in the PR comments if it's more a

Re: [Bitcoin-development] The Bitcoin Node Market

On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote: > Would SPV wallets have to pay to connect to the network too? From the > user's perspective, it would be somewhat upsetting (and confusing) to see > your balance slowly draining every time you open your wallet app. It would > also tie up out

Re: [Bitcoin-development] The Bitcoin Node Market

On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr wrote: > On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote: > > Would SPV wallets have to pay to connect to the network too? From the > > user's perspective, it would be somewhat upsetting (and confusing) to see > > your balance slowly draining e

Re: [Bitcoin-development] The Bitcoin Node Market

Would SPV wallets have to pay to connect to the network too? From the user's perspective, it would be somewhat upsetting (and confusing) to see your balance slowly draining every time you open your wallet app. It would also tie up outputs every time you open up your wallet. You may go to pay for so

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

> On Jun 15, 2015, at 3:54 PM, odinn wrote: > > I also disagree with the notion that everybody's just ok with what > Mike and Gavin are doing specifically, this statement by Mike > > > The consensus you seek does exist. All wallet developers (except > > Lawrence), all the major exchanges, a

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

Aaron, My understanding is that Gavin and Mike are proceeding with the XT fork, I hope that understanding is wrong. As for improving the non-consensus code to handle full blocks more gracefully. This is something I'm very interested in, block size increase or not. Perhaps I shouldn't hijack this

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine wrote: > Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core > maintainers simply refuse to lift the 1Mb limit? No one wants to go that > route. An alternate hard-fork proposal like BIP100 that gets consensus, or > a modified v

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core maintainers simply refuse to lift the 1Mb limit? No one wants to go that route. An alternate hard-fork proposal like BIP100 that gets consensus, or a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or

Re: [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork

http://xtnodes.com/ From: Brian Hoffman Sent: Monday, June 15, 2015 3:56 PM To: Faiz Khan Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork Who is actually planning to move to Bitcoin-XT if this happens? Just Gavin and Mike?

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

Who is actually planning to move to Bitcoin-XT if this happens? Just Gavin and Mike? > On Jun 15, 2015, at 6:17 PM, Faiz Khan wrote: > > I'm quite puzzled by the response myself, it doesn't seem to address some of > the (more serious) concerns that Adam put out, the most important question

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike, To sum it up, you are saying "bitcoin will break and many of our users will leave therefore OMG WTF so we have to do what GAVIN AND ME want to do to hardfork to XT which is the ONLY WAY, so GTFO!" And so, no. We don't have to accept that attit

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

I'm quite puzzled by the response myself, it doesn't seem to address some of the (more serious) concerns that Adam put out, the most important question that was asked being the one regarding personal ownership of the proposed fork: "How do you plan to deal with security & incident response for the

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn wrote: > Re: anyone who agrees with noted non-programmers Mike&Gavin must be > non-technical, stupid, uninformed, etc OK, go ahead and show them the > error of their ways. Anyone can write blogs. > I worry that if this is the level of care you tak

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

Mark Friedenbach writes: > There's another important use case which you mentioned Greg, that also > requires special exemption: compact commitments via mid-state compression. > > The use case is an OP_RETURN output sorted last, whose last N bytes are a > commitment of some kind. A proof of the com

Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs

Kristov Atlas writes: > Hello all, > > I have written a draft of a BIP to standardize the sorting of tx inputs and > outputs for privacy and security reasons. A few colleagues have reviewed > this and provided feedback privately, but now it's ready for feedback from > a wider audience. > > If ther

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

Hi Adam, I replied publicly because your questions were sent to the mailing list. I'd have been happy to reply in private if so asked. I started to write up a much longer reply, but I'm tired - we've long since been going in circles. I feel like I've written down answers to almost all your questi

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

On Mon, Jun 15, 2015 at 9:45 PM, Adam Weiss wrote: > ps. I think SF will let project admins download mbox archives of the list, > the new admins should be able to import them to keep archive consistency in > one place. > That seems to be right. I just downloaded the entire archive of this list (

Re: [Bitcoin-development] The Bitcoin Node Market

Hi Raystonn On Mon, Jun 15, 2015 at 9:36 PM, Raystonn . wrote: > > I am only partially through the content at the below link, and I am very > impressed. Has Justus Ranvier began work on implementation of the ideas > contained therein? I don't know if he or someone else has begun writing code

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

Recent versions of mailman strip DKIM signatures, rewrite the envelope-from to use an address at the list's domain and set reply-to to the original authors address to resolve the DMARC issue. I'm on several lists that do this and it works just fine. +1 on moving the list. Given the fact that the

Re: [Bitcoin-development] The Bitcoin Node Market

I am only partially through the content at the below link, and I am very impressed. Has Justus Ranvier began work on implementation of the ideas contained therein? From: sick...@gmail.com Sent: Monday, June 15, 2015 12:18 PM To: Raystonn . Cc: Bitcoin Dev Subject: Re: [Bitcoin-development]

Re: [Bitcoin-development] The Bitcoin Node Market

Sorry for top posting and the brevity but I'm typing from my phone You shoud be interested in this post by Justus Ranvier then: https://bitcoinism.liberty.me/economic-fallacies-and-the-block-size-limit-part-2-price-discovery/ On Jun 15, 2015 8:57 PM, "Raystonn ." wrote: > I have been toying wit

[Bitcoin-development] The Bitcoin Node Market

I have been toying with an idea and figured I'd run it by everyone here before investing further time in it. The goal here is to make it sustainable, and perhaps profitable, to run full nodes on the Bitcoin Network in the long term. - Nodes can participate in a market wherein they are paid by

Re: [Bitcoin-development] comments on BIP 100

I think he's more talking about like extension-blocks, however they are actually soft-forkable even (and keep the 21m coins obviously) See See https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07937.html and Tier Nolan tech detail https://www.mail-archive.com/bitcoin-d

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

Hi Mike Well thank you for replying openly on this topic, its helpful. I apologise in advance if this gets quite to the point and at times blunt, but transparency is important, and we owe it to the users who see Bitcoin as the start of a new future and the$3b of invested funds and $600m of VC fun

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

Side chains are a way to scale and shard horizontally while still retaining primary security parameters of the main chain. The future is an Internet of chains, a forest of chains with bitcoin as the root chain for: factom / proofofexistence, ChainDB, Blockstream side chains, merge mined side chain

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

Pieter: I kind of see your point (but I think you're missing some key points). You mean just download all the headers and then just verify the transactions you filter out by using their corresponding merkle trees, right? But still, I don't think that would scale as well as with the tree structure I

Re: [Bitcoin-development] comments on BIP 100

> The solution is to hard-fork and merge-mine. This way, both can live, and > mining power is not divided. No, this would essentially be blessing an increase to 42M bitcoins, half on each chain. You could expect a severe market price correction if this were to happen. From: Rebroad (sourcefor

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

> > It's simple: either you care about validation, and you must validate > everything, or you don't, and you don't validate anything. > Pedantically: you could validate a random subset of all scripts, to give yourself probabilistic verification rather than full vs SPV. If enough people do it with a

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille wrote: > It's simple: either you care about validation, and you must validate > everything, or you don't, and you don't validate anything. Sidechains do > not offer you a useful compromise here, as well as adding huge delays and > conplexity. > As n

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

If you are fine with the SPV security model, you are much better off by just increasing the Bitcoin block size and using an SPV client, as those do not care or even see the full block size by only downloading transactions they care about. Infinite scalability! The problem with scaling is that ulti

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

Hi All, I talked with Pieter off-list. And I guess the main opposition is that coins that are coming from chains that you are not directly validating are not fully validated by you in the sense that you only get an SPV type proof to prove that miners have accepted those coins. Yes, it's true, but

[Bitcoin-development] Test

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

Re: [Bitcoin-development] BIP for Proof of Payment

2015-06-15 12:00 GMT+02:00 Pieter Wuille : > I did misunderstand that. That changes things significantly. > > However, having paid is not the same as having had access to the input > coins. What about shared wallets or coinjoin? Wallets will have the same ability to make PoPs as they have in makin

Re: [Bitcoin-development] comments on BIP 100

My understanding of this debate is that there are some people who want to keep Bitcoin at 1MB block limit, and there are some who want to increase it. I for one am curious to see how 1MB limited bitcoin evolves, and I believe we can all have a chance to see this AND hard-fork bitcoin to remove the

Re: [Bitcoin-development] comments on BIP 100

> > The fact that using a centralized service is easier isn't a good reason > IMHO. It disregards the long-term, and introduces systemic risk. > Well sure, that's easy for you to say, but you have a salary :) Other developers may find the incremental benefits of decentralisation low vs adding addi

Re: [Bitcoin-development] comments on BIP 100

On Mon, Jun 15, 2015 at 12:36 PM, Mike Hearn wrote: > > Since you keep bringing this up, I'll try to clarify this once again. >> > > I understand the arguments against it. And I think you are agreeing with > me - Adam is bemoaning the way developers outsource stuff to third party > services, and

Re: [Bitcoin-development] comments on BIP 100

> > Since you keep bringing this up, I'll try to clarify this once again. > I understand the arguments against it. And I think you are agreeing with me - Adam is bemoaning the way developers outsource stuff to third party services, and suggesting it is relevant to the block size debate. And we are

Re: [Bitcoin-development] comments on BIP 100

On Mon, Jun 15, 2015 at 11:27 AM, Mike Hearn wrote: > I persevered for several months to add a very small "API" I needed for my > app to Bitcoin Core, and it was in the end a waste of time. There are no > actionable items left for the getutxo patch, regardless, I had to fork > Bitcoin to get it o

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

Bear in mind the problem that stops Jeff's messages getting through is that mailman 1.0 doesn't know how to handle DKIM properly. Switching to a different mailman provider won't fix that. Does mailman 3.0 even fix this? I found it difficult to tell from their website. There's a big page on the mai

Re: [Bitcoin-development] BIP for Proof of Payment

I did misunderstand that. That changes things significantly. However, having paid is not the same as having had access to the input coins. What about shared wallets or coinjoin? Also, if I understand correctly, there is no commitment to anything you're trying to say about the sender? So once I ob

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

Hi Adam, Provisional answers below! - Are you releasing a BIP for that proposal for review? > The work splits like this: - Gavin is writing the code and I think a BIP as well - I will review both and mostly delegate to Gavin's good taste around the details, unless there is some very s

Re: [Bitcoin-development] comments on BIP 100

>OK. O() notation normally refers to computational complexity, but ... I still don't get it - the vast >majority of users don't run relaying nodes that take part in gossiping. They run web or SPV >wallets. And the nodes that do take part don't connect to every other node. It's a little scary, IMO,

Re: [Bitcoin-development] comments on BIP 100

> > That was probably insufficiently specific, let me rephrase: I am > referring to the trend that much of the industry is built on web2.0 > technology using bitcoin via a library in a web scripting language OK, good to hear that. I'm not happy about the use of web technologies in wallets/service

Re: [Bitcoin-development] BIP for Proof of Payment

Hi all! I have made the discussed changes and updated my implementation ( https://github.com/kallerosenbaum/poppoc) accordingly. These are the changes: * There is now only one output, the "pop output", of value 0. * The sequence number of all inputs of the PoP must be set to 0. I chose to set it

Re: [Bitcoin-development] Proposal: Move Bitcoin Dev List to a Neutral Competent Entity

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What about Gittorrent? http://blog.printf.net/articles/2015/05/29/announcing-gittorrent-a-decen tralized-github/ On 06/14/2015 08:19 PM, Warren Togami Jr. wrote: > On Sun, Jun 14, 2015 at 5:15 AM, Jeff Garzik > wrote: > >

Re: [Bitcoin-development] comments on BIP 100

> StrawPay hasn't published any details of their work publicly; if they > wanted credit on the mailing list they should have done that. > There's a brief discussion here: https://www.reddit.com/r/Bitcoin/comments/2r3ri7/strawpay_cheap_and_secure_micropayments/ But yes, they are developing it be