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,
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
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
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 mobile
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
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
On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr l...@dashjr.org 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
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
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
On Jun 15, 2015, at 3:54 PM, odinn odinn.cyberguerri...@riseup.net 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
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
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 incentive people
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
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
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
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
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
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
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?
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 faizkha...@gmail.com 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
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
21 matches
Mail list logo
