On 26 August 2015 at 01:29, Peter Todd via bitcoin-dev
wrote:
> For instance, a very simple toy example that would work is just XORing your
> vote with SHA256(the entire blockchain)
Uh, that would totally not work.
I think my proposal of using CLTV to lock coins (votes) is better.
Failing a sof
That guy is going to easily make back his 150 BTC with interest, if he
is short BTC. Should be a clear signal for the market to trend lower,
probably below $180 by the time of the test.
On 23 August 2015 at 19:08, jl2012 via bitcoin-dev
wrote:
> Someone is going to burn 150BTC to create a backlog
Security is provided via POW. If you want the chains to stop attacking
each other, change the POW algorithms.
Then it wouldn't matter if one chain was longer than another, each
fork would select the best chain according to their valid version of
POW algorithm.
If Bitcoin Core loses miner majority t
Haha. Reminds me of when I asked Gavin earlier this year about whether
he cared about politics and he replied that he only cared about and
was responsible for the technicals. Little did he know he would
unwittingly become the technical enabler for Mike's political
shenanigans.
On 19 August 2015 at
On 19 August 2015 at 13:44, Jameson Lopp wrote:
> It's possible to check that a transaction is cryptographically valid without
> having any blockchain data available; are you referring to a different type
> of validation?
It seems laborious to enumerate all the validations that are performed
on a
On 19 August 2015 at 13:08, Jameson Lopp wrote:
> If operating as an SPV node then it can check the transactions by querying
> other nodes.
SPV is for checking validity of transactions that have already entered
the blockchain, as I understand it. My proposal requires nodes to
validate transaction
On 19 August 2015 at 12:42, Jameson Lopp wrote:
> If you can actually come up with a technical solution that allows for a node
> operator to prove to the rest of the network that they are running an honest
> full node that hosts the entire blockchain, then you can move forward with a
> direct mone
Bitcoin is imploding due to a failure of consensus. There has been a
failure of consensus on how to fix the design flaw evinced by the block
size fiasco.
On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I suspect we need a better incent
On 15 August 2015 at 18:43, Satoshi Nakamoto via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I suspect we need a better incentive for users to run nodes instead of
> relying solely on altruism.
>
Is he talking about "full nodes" i.e. validating-only, or nodes in the
sense of the
Lightning will never catch on as it basically demands that everyone who
uses it to become a speculator. Payment hubs and merchants will be at the
mercy of the bitcoin price while their funds stay locked up in payment
channels. This idea is a dead-end.
On 10 August 2015 at 22:43, Adam Back via bitc
Nonsense. Hoping that the bitcoin price will rise is called speculation.
Hub operators won't want to do that, since prices can go down as well as
up. The money markets and government bond yield curve prices risk-free
rates of return, a guaranteed rise in value. These rates are always
positive.
On
On 10 August 2015 at 19:50, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> ...but I think at present the time value of bitcoin is effectively zero
Since bitcoin is liquid you forget that one can just sell off his bitcoin
for fiat and hold that for interest. The t
Sorry about that Patrick. Gmail hides previous messages including sender
names. Regardless, no worries.
On 9 August 2015 at 23:27, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> That was not in reply to you.
>
>
> On 08/09/2015 03:09 PM, Hector Chu wrote:
>
>
Right, you've stated a bunch of facts, but how does it answer my concerns
of the exploding cost of the network the more interconnected it it?
On 9 August 2015 at 23:06, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I suspect there is some amount of confusion
loss of control of private keys (the keys necessarily
> need to be on an internet connected system).
> Operating costs (I expect this will be minimal).
>
> The hub can charge a fee for it's services to recoup these costs.
>
>
> On 08/09/2015 02:45 PM, Hector Chu via bit
Tom, my understanding is that the money that is debited from a payment hub
is simultaneously credited from either another payment hub or the person
making the payment, so that the net funds flow at a payment hub always sums
to zero. So no, there is no credit advanced by the payment hub to anyone.
Thanks Mark.
Ok next obvious question (apologies for all of these but it seems you are
the authority on Lightning here). Is the Lightning system limited in the
number of hops there can be in the payment channel? I am looking at the
initial Lightning slides presented in February and it looks like th
In the Lightning network it is assumed that the balances can always be
settled on the blockchain if any of the parties along the channel has a
problem. What if the fee on the settlement transactions is not high enough
to enter the blockchain? You can't do replace-by-fee after the fact. Do the
fees
You people are the most selfish kind of people in the world. Blackmail
developers with overload of the system, to try to force them to urgently
come up with solutions to the problem. The solution is always going to
be... wait for it... "increase the block size". There is not enough time or
manpower
I think that if a vote was free, no matter how much weight it carried, then
it could be easily bought and the vote manipulated. If the cost of the vote
was proportional to its weight, then it would be harder to manipulate the
vote.
I know I haven't explained that thoroughly, but as an analogy think
o the
time-value of money and has a cost the longer they are locked up for.
On 8 August 2015 at 15:23, Peter Todd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 8 August 2015 02:27:35 GMT-04:00, Hector Chu via bitcoin-dev <
> bitcoin-dev@lists.linux
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
To put some flesh on the bones of this idea, imagine a hypothetical
security named BLK. Demand for bigger blocks should buy up BLK and demand
for smaller blocks should short BLK. The price of BLK in BTC is the ideal
block size.
Now imagine that there are futures contracts for the security BLK. On t
On 5 August 2015 at 12:07, Adam Back wrote:
> This prediction market in block-size seems like something extremely
> complex to operate and keep secure in a decentralised fashion.
Why would it need to be decentralised? Bitcoin.org could run the exchange,
and the profits from the exchange could b
On 5 August 2015 at 10:57, Adam Back wrote:
> You may find the flexcap idea summarised in outline by Greg Maxwell
> and Mark Friedenbach a month or so back interesting in showing that
> one can achieve such effects without handing over a free vote to
> miners and hence avoid many (though probably
On 5 August 2015 at 09:33, Benjamin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> A market means that demand and supply are matched continuously, and
> Bitcoin has no such mechanism.
>
Not all markets need to have highly liquid trading outlets in order to be
thought of as such
On 4 August 2015 at 14:13, Jorge Timón wrote:
> 2) It doesn't matter who is to blame about the current centralization:
> the fact remains that the blocksize maximum is the only** consensus
> rule to limit mining centralization.
>
Repeating a claim ad-nauseum doesn't make it necessarily true. A b
On 4 August 2015 at 12:59, Jorge Timón wrote:
> That is not my position. Again, I don't know what the right blocksize
> for the short term is (I don't think anybody does).
>
You have no position (i.e. neutral). In other words, keeping the existing
limit.
> Therefore how the change can affect m
lets, and mining is done by a cartel that
> only allows joining after signing a contract so they can sue you if you
> create an invalid block. Do you think people will then agree that "things
> got demonstratebly worse"?
>
> Don't turn Bitcoin into something
Mike's position is that he wants the block size limit
to eventually be removed. That is of course an extreme view. Meanwhile,
your view that the block size should be artificially constrained below the
organic growth curve (in a way that will penalize a majority of existing
and future users) lies at
On 4 August 2015 at 10:03, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> If you want to let a majority decide about economic policy of a currency,
> I suggest fiat currencies. They have been using this approach for quite a
> while, I hear.
>
Nearly all the fiat cu
ss? The very model upon which the security of the system is
>>> based *broke*…as in, we were only able to recover because a few individuals
>>> deliberately manipulated the consensus rules to fix it manually. Shouldn’t
>>> we more highly prioritize fixing the
; deliberately manipulated the consensus rules to fix it manually. Shouldn’t
>> we more highly prioritize fixing the issues that can lead to these
>> incidents than trying to increase throughput? Increasing block size cannot
>> possibly make these forking tendencies better…but i
roughput? Increasing block size cannot
> possibly make these forking tendencies better…but it very well could make
> them worse.
>
> - Eric
>
> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On 3 August 20
On 3 August 2015 at 08:53, Adam Back wrote:
> Again this should not be a political or business compromise model - we
> must focus on scientific evaluation, technical requirements and
> security.
>
I will assert that the block size is political because it affects nearly
all users to some degree a
On 3 August 2015 at 08:16, Simon Liu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Increasing the block size shouldn't be a problem for Chinese miners.
> Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
> already signed a draft agreement indicating they are fin
On 1 August 2015 at 01:17, Gregory Maxwell wrote:
> One can quite easily transact in a way to intentionally produce such a
> split to seperate the existance of your coins onto the seperate forks;
> just as anyone would need to do to perform a reorg-and-respend attack
> on a single blockchain.
>
I haven't seen much discussion on this list of what will happen when the
blockchain forks due to larger blocks. I think the debate surrounding this
issue is a storm in a teacup, because transactions on the smaller chain can
and will appear on the bigger chain also. There is nothing tying
transactio
39 matches
Mail list logo
