On Mon, Dec 07, 2015 at 10:02:17PM +, Gregory Maxwell via bitcoin-dev wrote:
> The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating
> proposals were presented. I think this would be a good time to share my
> view of the near term arc for capacity increases in the Bitcoin sys
On Dec 8, 2015 7:08 PM, "Wladimir J. van der Laan via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> - Gregory linked to an implementation but as he mentions it is not
completely
> finished yet. ETA for a Segwit testnet is later this month, then you
can test as well.
Testnet4
Hi all. I've been working on a new publication platform based on Bitcoin
called key.run: http://key.run
The high level overview is that key.run stores BitTorrent info hashes
(magnet links) in the blockchain by sending transactions to a "namespace"
Bitcoin address. Using SPV, I reconstitute the key
I am leaning towards supporting a can kick proposal. Features I think are
desirable for this can kick:
0. Block size limit around 2 to 4 MB. Maybe 3 MB? Based on my testnet data, I
think 3 MB should be pretty safe.
1. Hard fork with a consensus mechanisms similar to BIP101
2. Approximately 1 or
So I have been told more than once that the version announcement in blocks
is not a vote, but a signal for readiness, used in isSupermajority().
Basically, if soft forks (and hard forks) won't activate unless a certain %
of blocks have been flagged with the version up (or bit flipped when
versionbi
Thanks for laying out a road-map, Greg.
I'll need to think about it some more, but just a couple of initial
reactions:
Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the
coinbase is messy and will just complicate consensus-critical code (as
opposed to making the right side
On 12/08/2015 09:12 AM, Gavin Andresen via bitcoin-dev wrote:
> Stuffing the segwitness merkle tree in the coinbase
If such a change is going to be deployed via a soft fork instead of a
hard fork, then the coinbase is the worst place to put the segwitness
merkle root.
Instead, put it in the first
Hello,
I am seeking some expert feedback on an idea for scaling Bitcoin. As a
brief introduction: I work in the payment industry and I have twenty years'
experience in development. I have some experience with process groups and
ordering protocols too. I think I understand Satoshi's paper but I adm
On Tue, Dec 8, 2015 at 10:27 AM, Akiva Lichtner via bitcoin-dev
wrote:
> and miners would have to round-robin through partitions
At first glance this proposal seems most similar to the sharding proposals:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
https://github.co
A far better place than the generation transaction (which I assume means
coinbase transaction?) is the last transaction in the block. That allows
you to save, on average, half of the hashes in the Merkle tree.
On Tue, Dec 8, 2015 at 11:55 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists.linu
Thanks for your response and links.
I think the difference is that those proposals all shard the mining work,
whereas what I wrote in my post shards the coin itself. In other words
different parts of the coin space are forever segregated, never ending up
in the same block. It's a big difference co
On 12/08/2015 11:41 AM, Mark Friedenbach wrote:
> A far better place than the generation transaction (which I assume means
> coinbase transaction?) is the last transaction in the block. That allows
> you to save, on average, half of the hashes in the Merkle tree.
I don't care what color that bikes
On Tue, Dec 8, 2015 at 5:41 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> A far better place than the generation transaction (which I assume means
> coinbase transaction?) is the last transaction in the block. That allows
> you to save, on average, half of
On Tue, Dec 8, 2015 at 3:55 PM, Justus Ranvier via bitcoin-dev
wrote:
> Instead, put it in the first output of the generation transaction as an
> OP_RETURN script.
Pieter was originally putting it in a different location; so it's no
big deal to do so.
But there exists deployed mining hardware th
I proposed in my Wildcard Inputs BIP that the version field be split
in two. The first 4 bytes are version number (which in practice is
being used for script version), and the second 4 bits are used for
transaction type.
I don't think the BIP9 mechanism really applies to transactions. A
block is e
Payment recipients would need to operate a daemon for each chain, thus
guaranteeing no scaling advantage.
(There are other issues, but I believe that to be enough of a show
stopper not to continue).
On 12/08/2015 08:27 AM, Akiva Lichtner via bitcoin-dev wrote:
> Hello,
>
> I am seeking some exper
I suppose whether the wallet devs want to implement the soft fork or not is
irrelevant. They only need to indicate if they are ready i.e. they've
tested the new soft fork, hard fork or feature and validated that it
doesn't break their nodes or wallet software.
On Dec 9, 2015 6:40 AM, "Chris Priest"
It's true that miners would have to be prepared to work on any partition. I
don't see where the number affects defeating double spending, what matters
is the nonce in the block that keeps the next successful miner random.
I expect that the number of miners would be ten times larger as well, so an
If partition is selected from a random key (the hash of the output for
example) then payment recipients would need to operate a full node on
each of the chains.
What's the point of partitioning if virtually everybody needs to operate
each partition?
The mining aspect has it's own set of issues, b
A wallet doesn't receive transactions from other wallets. That is what
a node does. Wallets just make transactions and then sends them to the
nodes. Nodes then send them to other nodes.
In the early days of bitcoin, all wallets were nodes, but now a lot of
wallets are just wallets with out any spe
Agree. This data does not belong in the coinbase. That space is for miners to
use, not devs.
I also think that a hard fork is better for SegWit, as it reduces the size of
fraud proofs considerably, makes the whole design more elegant and less
kludgey, and is safer for clients who do not upgrade
On Dec 8, 2015, at 6:02 AM, Gregory Maxwell via bitcoin-dev
wrote:
> The particular proposal amounts to a 4MB blocksize increase at worst.
I understood that SegWit would allow about 1.75 MB of data in the average case
while also allowing up to 4 MB of data in the worst case. This means that th
On Tuesday, December 08, 2015 11:40:42 PM Jonathan Toomim via bitcoin-dev
wrote:
> Agree. This data does not belong in the coinbase. That space is for miners
> to use, not devs.
This has never been guaranteed, nor are softforks a "dev action" in the first
place.
> I also think that a hard fork
On Dec 9, 2015 7:41 AM, "Jonathan Toomim via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I also think that a hard fork is better for SegWit, as it reduces the
size of fraud proofs considerably, makes the whole design more elegant and
less kludgey, and is safer for clients who do
On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev
wrote:
> Why segwitness as a soft fork? Stuffing the segwitness merkle tree in the
> coinbase is messy and will just complicate consensus-critical code (as
> opposed to making the right side of the merkle tree in block.version=5
> bloc
On Tue, Dec 8, 2015 at 11:48 PM, Jonathan Toomim wrote:
> I understood that SegWit would allow about 1.75 MB of data in the average
> case while also allowing up to 4 MB of data in the worst case. This means
> that the mining and block distribution network would need a larger safety
> factor to de
On Dec 9, 2015, at 8:09 AM, Gregory Maxwell wrote:
> On Tue, Dec 8, 2015 at 11:48 PM, Jonathan Toomim wrote:
>
> By contrast it does not reduce the safety factor for the UTXO set at
> all; which most hold as a much greater concern in general;
I don't agree that "most" hold UTXO as a much grea
On Dec 9, 2015, at 7:48 AM, Luke Dashjr wrote:
> How about we pursue the SegWit softfork, and at the same time* work on a
> hardfork which will simplify the proofs and reduce the kludgeyness of merge-
> mining in general? Then, if the hardfork is ready before the softfork, they
> can both go tog
On Dec 9, 2015, at 7:50 AM, Jorge Timón wrote:
> I don't undesrtand. SPV nodes won't think they are validating transactions
> with the new version unless they adapt to the new format. They will be simply
> unable to receive payments using the new format if it is a softfork (although
> as said
On Wed, Dec 9, 2015 at 12:59 AM, Gregory Maxwell via bitcoin-dev
wrote:
> On Tue, Dec 8, 2015 at 3:12 PM, Gavin Andresen via bitcoin-dev
> wrote:
> We already have consensus critical enforcement there, the height,
> which has almost never been problematic. (A popular block explorer
> recently mis
On Wed, Dec 9, 2015 at 1:58 AM, Jorge Timón wrote:
> struct hashRootStruct
> {
> uint256 hashMerkleRoot;
> uint256 hashWitnessesRoot;
> int32_t nHeight;
> }
Or better, for forward compatibility (we may want to include more
things apart from nHeight and hashWitnessesRoot in the future):
struct ha
On Tue, Dec 8, 2015 at 6:59 PM, Gregory Maxwell wrote:
> > We also need to fix the O(n^2) sighash problem as an additional BIP for
> ANY
> > blocksize increase.
>
> The witness data is never an input to sighash, so no, I don't agree
> that this holds for "any" increase.
>
Here's the attack:
Cre
On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen wrote:
> Create a 1-megabyte transaction, with all of it's inputs spending
> segwitness-spending SIGHASH_ALL inputs.
>
> Because the segwitness inputs are smaller in the block, you can fit more of
> them into 1 megabyte. Each will hash very close to o
If the system is modified to scale up that means the number of transactions
is going up. That means the number of miners can also go up, and so will
the portion of malicious nodes. At least this seems reasonable. The problem
with partitions is that an attacker can focus on one partition. However
be
On Wed, Dec 09, 2015 at 01:31:51AM +, Gregory Maxwell via bitcoin-dev wrote:
> On Wed, Dec 9, 2015 at 1:09 AM, Gavin Andresen
> wrote:
> > Create a 1-megabyte transaction, with all of it's inputs spending
> > segwitness-spending SIGHASH_ALL inputs.
> > Because the segwitness inputs are smalle
>I agree, but nothing I have advocated creates significant technical
>debt. It is also a bad engineering practice to combine functional
>changes (especially ones with poorly understood system wide
>consequences and low user autonomy) with structural tidying.
I don't think I would classify placing
On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler wrote:
>>I agree, but nothing I have advocated creates significant technical
>>debt. It is also a bad engineering practice to combine functional
>>changes (especially ones with poorly understood system wide
>>consequences and low user autonomy) with stru
Dear Akiva,
Its Loi Luu, one of the authors of the SCP protocol (
http://eprint.iacr.org/2015/1168.pdf ).
Before SCP, we had been thinking hard about how to do sharding efficiently
without degrading any security guarantee. A simple solution which splits
the coins, or TXs in to several partitions
I see, thanks for clearing that up, I misread what Gavin stated.
On Wed, Dec 9, 2015 at 12:29 AM, Gregory Maxwell wrote:
> On Wed, Dec 9, 2015 at 4:44 AM, Ryan Butler wrote:
> >>I agree, but nothing I have advocated creates significant technical
> >>debt. It is also a bad engineering practice t
Greg, if you have actual data showing that putting the commitment in the
last transaction would be disruptive, and how disruptive, that would be
appreciated. Of the mining hardware I have looked at, none of it cared at
all what transactions other than the coinbase are. You need to provide a
path to
On Wed, Dec 9, 2015 at 6:59 AM, Mark Friedenbach wrote:
> Greg, if you have actual data showing that putting the commitment in the
> last transaction would be disruptive, and how disruptive, that would be
> appreciated. Of the mining hardware I have looked at, none of it cared at
> all what transa
On Wed, Dec 9, 2015 at 7:29 AM, Gregory Maxwell via bitcoin-dev
wrote:
> What was being discussed was the location of the witness commitment;
> which is consensus critical regardless of where it is placed. Should
> it be placed in an available location which is compatible with the
> existing netwo
42 matches
Mail list logo
