Also there may need to be weighting depending on how long the coins have
been locked for, to stop voting at the last minute having an undue
influence.
On 8 August 2015 at 07:27, Hector Chu wrote:
> Has there ever been any discussion of locking coins till a certain date
> for casting votes on an
Has there ever been any discussion of locking coins till a certain date for
casting votes on an issue?
Say that the date for counting votes is 3 months from now. Every one who
wants to cast a vote must lock coins until the vote closes (using CLTV). To
increase the weight of your vote, lock more co
On Friday 7. August 2015 23.53.43 Adam Back wrote:
> On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
> > As we concluded in our previous email, the need to run a node is inversely
> > proportional to the ability (or willingness) to trust others.
[]
> > And lets face it, practically everyon
Then I would suggest working on payment channel networks. No decrease of
the interblock time will ever compete with the approximately instant time
it takes to validate a microchannel payment.
On Fri, Aug 7, 2015 at 4:08 PM, Sergio Demian Lerner <
sergio.d.ler...@gmail.com> wrote:
> In some rare o
In some rare occasions in everyday life, what matters is seconds. Like when
paying for parking in the car while some other cars are behind you in the
line. You don't want them to get upset.
I takes me tens of minutes to shop. But once you choose your merchandise
and your payment starts processing,
Please try to focus on constructive technical comments.
On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
wrote:
> What will the backlash be when people here that are pushing for "off-chain-
> transactions" fail to produce a properly working alternative, which
> essentially means we have t
Actually I gave a cached answer earlier which on further review may need
updating. (Bad Mark!)
I presume by "what's more likely to matter is seconds" you are referencing
point of sale. As you mention yourself, lightning network or green address
style payment escrow obviates the need for short inte
On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
wrote:
> the need an individual has for running a node is a completely different
> concept than the
> need for nodes to exist. And, really, you are describing miners, not nodes.
It's not as simple as trusting miners, Bitcoin security need
Den 7 aug 2015 23:37 skrev "Sergio Demian Lerner via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
>
> Mark,
> It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have
On Friday 7. August 2015 19.33.34 Jorge Timón via bitcoin-dev wrote:
> When "the network runs out of capacity" (when we hit the limit) do we
> expect anything to happen apart from minimum market fees rising (above
> zero)?
How many clients actually evict transactions from their mempool currently?
On Friday 7. August 2015 20.10.48 Pieter Wuille wrote:
> But if the reason for increasing is because you fear a change of economics,
> then it means you prefer not dealing with that change.
Let me quote yourself;
On Thursday 6. August 2015 17.26.11 Pieter Wuille via bitcoin-dev wrote:
> I believ
On Friday 7. August 2015 20.10.48 Pieter Wuille wrote:
> On Aug 7, 2015 7:50 PM, "Gavin Andresen" wrote:
> > I believe people in the Bitcoin ecosystem will choose different
> > tradeoffs, and I believe that is OK-- people should be free to make those
> > tradeoffs.
>
> I agree. Though I believe t
Mark,
It took you 3 minutes to respond to my e-mail. And I responded to you 4
minutes later. If you had responded to me in 10 minutes, I would be of out
the office and we wouldn't have this dialogue. So 5 minutes is a lot of
time.
Obviously this is not a technical response to the technical issues
On Friday 7. August 2015 19.09.30 Pieter Wuille wrote:
> > And you do the same thing again; you dismiss the need factor.
>
> Of course there is a need. It's the primary mechanism that keeps Bitcoin
> secure and immune from malicious influence.
I see a pretty big problem if this really is your ins
On Fri, Aug 7, 2015 at 10:16 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But perhaps there is some "use" for ultra-low-priority unreliable
> transactions (... despite DoS attacks).
>
I can think of a variety of protocols that broadcast information and don
Because halving the block interval comes with costs to SPV proofs (which
double the number of headers) and mining centralization (doubles the
selfish mining effect of latency) for the questionable benefit of a block
expectation time that is still measured in minutes, not seconds.
Doubling the bloc
What would you do?
a. Double the block size
b. Reduce the block rate to a half (average 5 minute blocks)
Suppose this is a one time hard fork. There no drastic technical problems
with any of them: "SPV" mining and the relay network has shown that block
propagation is not an issue for such as smal
> On 7 Aug 2015, at 16:17, Ryan Butler via bitcoin-dev
> wrote:
>
> A raspberry pie 2 node on reasonable Internet connection with a reasonable
> hard drive can run a node with 8 or 20mb blocks easily.
>
I'm curious as I've not seen any data on this subject. How fast can a RP2 do
the necessar
Peter's proposal undercuts matching blocksize growth to technological
progress not limiting centralization pressure. They are somewhat related,
but I want to be clear on what I originally stated. I would also point out
that Peter's proposal lacks this technical criteria as well.
That being said,
Surely you have some sort of empirical measurement demonstrating the
validity of that statement? That is to say you've established some
technical criteria by which to determine how much centralization pressure
is too much, and shown that Pieter's proposal undercuts expected progress
in that area?
Clarification...
These are not mutually exclusive. We can design an increase to blocksize
that increases available space on chain AND follow technological
evolution. Peter's latest proposal is way too conservative on that front.
And given Peter's assertion that demand is infinite there will sti
Who said anything about scaling bitcoin to visa levels now? We're talking
about an increase now that scales into the future at a rate that is
consistent with technological progress.
Peter himself said "So, I think the block size should follow technological
evolution...".
The blocksize increase p
Hi,
Hope it is OK to post this on the list, was not sure where else to post
for answers from Bitcoin-Qt client developers.
As part of the Open Bitcoin Privacy Project’s ongoing wallet privacy
measurement efforts, we’ve selected the Bitcoin-Qt client v0.11.0 for
inclusion into our 2015 mid ye
> ...blocks are found at random intervals.
>
> Every once in a while the network will get lucky and we'll find six blocks in
> ten minutes. If you are deciding what transaction fee to put on your
> transaction, and you're willing to wait until that six-blocks-in-ten-minutes
> once-a-week event,
That's a good question.
An argument has been put forward that a larger block size would reduce
the security of the network, so does the converse hold?
On 08/07/2015 11:17 AM, jl2012 via bitcoin-dev wrote:
> What if we reduce the block size to 0.125MB? That will allow 0.375tx/s.
> If 3->24 sound
On Fri, Aug 7, 2015 at 1:17 PM, jl2012 via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> No, I'm not trolling. I really want someone to tell me why we
> should/shouldn't reduce the block size. Are we going to have more or less
> full nodes if we reduce the block size?
Some argume
Please don't put words into Pieter's mouth. I guarantee you everyone
working on Bitcoin in their heart of hearts would prefer everyone in the
world being able to use the Bitcoin ledger for whatever purpose, if there
were no cost.
But like any real world engineering issue, this is a matter of trade
On 8 August 2015 at 00:57, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I answered:
>
>> > 1. If you are willing to wait an infinite amount of time, I think the
>> > minimum fee will always be zero or very close to zero, so I think it's a
>> > silly question.
>
Pieter Wuille via bitcoin-dev 於 2015-08-07 12:28 寫到:
On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen
wrote:
On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille
wrote:
I guess my question (and perhaps that's what Jorge is after): do
you feel that blocks should be increased in response to (or for
f
On Aug 7, 2015 7:50 PM, "Gavin Andresen" wrote:
>
>
> On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> If the incentives for running a node don't weight up against the
cost/difficulty using a full node yourself for a majority of p
Anecdotally I've seen two primary reasons posed for not running a node:
1) For enthusiasts who want to altruistically run a node at home, it's
usually a bandwidth / quality of service problem. There are tools to help
work around this, but most users aren't sysadmins and would prefer a simple
confi
On Fri, Aug 7, 2015 at 12:30 PM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If the incentives for running a node don't weight up against the
> cost/difficulty using a full node yourself for a majority of people in the
> ecosystem, I would argue that there is a
Interesting position there Peter...you fear more people actually using
bitcoin. The less on chain transactions the lower the velocity and the
lower the value of the network. I would be careful what you ask for
because you end up having nothing left to even root the security of these
off chain tra
On Aug 7, 2015 5:55 PM, "Gavin Andresen" wrote:
>
> I think there are multiple reasons to raise the maximum block size, and
yes, fear of Bad Things Happening as we run up against the 1MB limit is one
of the reasons.
What are the other reasons?
> I take the opinion of smart engineers who actually
On Fri, Aug 7, 2015 at 7:00 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > If the incentives for running a node don't weight up against the
> > cost/difficulty using a full node yourself for a majority of people in
> the
> > ecosystem, I would argue that ther
On Friday 7. August 2015 18.30.28 Pieter Wuille wrote:
> On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev <
> > But your conclusion that low node count is an indication that its hard
> > to run one discards your own point. You forget the point that running
> > a node is only needed if
On Fri, Aug 7, 2015 at 6:06 PM, Thomas Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> You make a logical fallacy;
>
> I would agree that nodes are there for people to stop trusting someone that
> they have no trust-relationship with.
>
Yay, trust!
> But your conclusion
On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen
wrote:
> On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille
> wrote:
>
>> I guess my question (and perhaps that's what Jorge is after): do you feel
>> that blocks should be increased in response to (or for fear of) such a
>> scenario.
>>
>
> I think the
On Monday 3. August 2015 11.22.14 Gavin Andresen via bitcoin-dev wrote:
> (my only big disagreement with those predictions is the 'Number of nodes'
> -- I don't think replace-by-fee would affect that number, and I think even
> with no change we will see the number of full nodes on the network drop
On Thursday 6. August 2015 20.52.28 Pieter Wuille via bitcoin-dev wrote:
> It's about reduction of trust. Running a full node and using it verify your
> transactions is how you get personal assurance that everyone on the network
> is following the rules. And if you don't do so yourself, the knowled
On Fri, Aug 7, 2015 at 11:16 AM, Pieter Wuille
wrote:
> I guess my question (and perhaps that's what Jorge is after): do you feel
> that blocks should be increased in response to (or for fear of) such a
> scenario.
>
I think there are multiple reasons to raise the maximum block size, and
yes, fe
On Fri, Aug 7, 2015 at 4:57 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Every once in a while the network will get lucky and we'll find six blocks
> in ten minutes. If you are deciding what transaction fee to put on your
> transaction, and you're willing to
Popping this into it's own thread:
Jorge asked:
> >> 1) If "not now", when will it be a good time to let the "market
> >> minimum fee for miners to mine a transaction" rise above zero?
>
I answered:
> > 1. If you are willing to wait an infinite amount of time, I think the
> > minimum fee will
Your proposal fails here:
"If the block defined in the Guarantee Message has not been shown"
What is blockchain? You can see blockchain as a mechanism to prove
something has been shown by certain order. Therefore, it is not possible
to prove something has not been shown with blockchain.
Your
44 matches
Mail list logo
