a single thing to change to Bitcoin, I would lower the payment time, even
within the minute scale.
Sergio
On Fri, Aug 7, 2015 at 7:46 PM, Natanael natanae...@gmail.com wrote:
Den 7 aug 2015 23:37 skrev Sergio Demian Lerner via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org:
Mark
In these shocking forking times, nothing more relaxing that to immerse
yourself in a pure technical reading about cryptocurrency design, letting
aside Bitcoin politics for a moment. This message is about cryptocurrencies
design in general, so you're free to skip my message if you think it will
Hector,
I can only say 2 things in the brief time I have now:
1. There is a solution that I proposed for proving you own a copy of the
block-chain. It's using aymmetric-time functions:
https://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/
2. I'm finishing a paper on a
, 2015 at 2:18 PM, Sergio Demian Lerner via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
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
Is there any up to date documentation about TheBlueMatt relay network
including what kind of block compression it is currently doing? (apart from
the source code)
Regards, Sergio.
On Wed, Aug 5, 2015 at 7:14 PM, Gregory Maxwell via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
On
On Mon, Aug 10, 2015 at 6:01 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
On Aug 7, 2015 11:19 PM, Sergio Demian Lerner via bitcoin-dev
bitcoin-dev@lists.linuxfoundation.org wrote:
b. Reduce the block rate to a half (average 5 minute blocks)
Suppose this is a one time hard fork
Guys,
I strongly think the original prabhat e-mail is a parody.
And I find very funny that important people have responded.
But maybe I'm wrong!
*:)*
El jue., 27 ago. 2015 a las 11:04, Chris Pacia via bitcoin-dev (
bitcoin-dev@lists.linuxfoundation.org) escribió:
On 08/27/2015 09:39 AM,
Some of the people on this mailing list are blindly discussing the
technicalities of a soft/hard fork without realizing that is not Mike's
main intention. At least I perceive (and maybe others too) something else
is happening.
Let me try to clarify: the discussion has nothing to do with technical
Congratulations!
It a property of the SKCP system that the person who performed the trusted
setup cannot extract any information from a proof?
In other words, is it proven hard to obtain information from a proof by the
buyer?
On Fri, Feb 26, 2016 at 6:42 PM, Gregory Maxwell via bitcoin-dev <
It seems that every message must be signed (the protocols lacks MACs). This
can be very resource consuming in terms of CPU and bandwidth since most p2p
messages are small.
On Wed, Mar 23, 2016 at 5:36 PM, Tom via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wednesday 23 Mar
Missing link to paper: https://arxiv.org/abs/1605.04559
Another relevant paper:
On Bitcoin as a public randomness source
Joseph Bonneau, Jeremy Clark, and Steven Goldfeder
https://eprint.iacr.org/2015/1015.pdf
On Tue, May 24, 2016 at 11:30 AM, Sergio Demian Lerner <
sergio.d.ler...@gmail.com>
On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
sergio.d.ler...@gmail.com> wrote:
>
>
> You can find it here:
> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
>
> Basically, the idea is to put in the first 64 bytes a 4 byte hash of the
> second 64-byte
Jorge Timón said..
> What do you mean by "embrace" in the context of a patented optimization
that one miner can prevent the rest from using?
Everyone seems to assume that one ASIC manufacturer will get the advantage
of AsicBoost while others won't. If a patent license is non-exclusive, then
all
Your idea of moving the Merkle root to the second chunk does not work.
The AsicBoost can change the version bits and it does not need to find a
collision.
(However *Spondoolies patent *only mentions Merkle collisions:
On Mon, Feb 13, 2017 at 8:58 AM, John Hardy wrote:
> Hi Sergio,
>
>
> Thanks for your response, interesting work, very excited for RSK.
>
>
> I like the ephemeral payload, I suppose that aspect of my proposal could
> be described as ephemeral blockspace.
>
>
> I'm curious
Hi John,
RSK platform (a Bitcoin sidechain) is already prepared to do something
similar to this, although very efficiently. We set apart 1% of the block
reward to automatically reward full nodes.
We have two systems being evaluated: the first is based on PoUBS (Proof of
Unique Blockchain
On Wed, Aug 17, 2016 at 9:19 PM, Gregory Maxwell <gmaxw...@gmail.com> wrote:
> On Thu, Aug 18, 2016 at 12:11 AM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I think that we're not attacking the real source of the problem: t
I think that we're not attacking the real source of the problem: that the
witness data size is not signed. It may be the case that a new source of
malleability is detected in witness programs later, or related to new
opcodes we'll soft-fork in the future.
The problem is real, as some systems
Because there was a discussion on reddit about this topic, I want to
clarify that Johnson Lau explained how a check in the code prevents this
attack.
So there is no real attack.
Also note that the subject of this thread has a question mark, which means
that I'm asking the community for
In a previous thread ("New BIP: Dealing with OP_IF and OP_NOTIF
malleability in P2WSH") it was briefly discussed what happens if someone
modifies segwit data during transmission. I think the discussion should
continue.
What worries me is what happens with non-segwit transactions after segwit
is
Since ScalingBitcoin is close, I think this is a good moment to publish our
proposal on drivechains. This BIP proposed the drivechain we'd like to use
in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented
in Bitcoin. Until that happens, we're using a federated approach.
I'm
Please Peter Todd explain here all what you want to say about a patent of a
hardware design for an ASIC.
Remember that ASICBoost is not the only patent out there, there are at
least three similar patents, filed by major Bitcoin ASIC manufacturers in
three different countries, on similar
believe it.
Let's open another thread elsewhere to discuss hardware and software
patents, and that particular one, if you wish, this is NOT the place.
On Sun, Oct 2, 2016 at 1:17 PM, Peter Todd <p...@petertodd.org> wrote:
> On Sun, Oct 02, 2016 at 12:49:08PM -0300, Sergio Demian L
I'm not a lawyer, and my knowledge on patents is limited. I guess RSK WILL
endorse DPL or will make the required actions to make sure the things
developed by RSK remain free and open. This was not a priority until now,
but coding was. For me, coding always is the priority.
I will discuss
It's good you bring that point, and it's very interesting to analyze what
happened then.
We shared our findings with some core developers much earlier than the BIP
proposal. Wether they kept it secret or they shared it with some ASIC
manufacturers is something I don't know. I even mentioned my
On Sun, Oct 2, 2016 at 6:46 PM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But I would argue that in this scenario, the only way it
>> would become invalid is the equivalent of a double-spend... and therefore
>> it
>> may be acceptable in relation to this
One side benefit of OP_COUNT_ACKS is that it enables a completely different
use case:
It allow users to pay for any service miners can provide as group for the
common good (e.g. fee payment smoothing over many blocks). For instance,
users could pay miners to jointly buy better Internet service to
I read the DPL v1.1 and I find it dangerous for Bitcoin users. Current
users may be confident they are protected but in fact they are not, as the
future generations of users can be attacked, making Bitcoin technology
fully proprietary and less valuable.
If you read the DPL v1.1 you will see that
uent miners. A honest pre-fork
miner would never include a redeemScript that that verifies an
OP_COUNT_ACKS, since that transaction would never be received by the p2p
protocol (it could if the miner accepts non-standard txs by a different
channnel).
But I must check this in the BIP source code if OP_COUNT
via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via
>> bitcoin-
>> dev wrote:
>> > Without a detailed analysis, unlimited block size seems a risky change
>> to
>&
On Fri, Nov 25, 2016 at 12:25 PM, Tom Zander via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thursday, 24 November 2016 22:39:05 CET Sergio Demian Lerner via
> bitcoin-
> dev wrote:
> > Without a detailed analysis, unlimited block size seems a risky
Hi Peter,
How would a person or exchange decide to accept a payment in BU if it does
not know the gate policy of 51% of the miners?
Suppose that the exchange receives B1,S2,S3,S4 (a big block at height 1,
and 3 small blocks at height 2, 3 and 4), and an alternate chain A1,A2,A3
(three small
Oh God... here we go again..
>
> Again, lets remember that you personally proposed a BIP[1] that had the
> effect
> of aiding your ASICBOOST patent[2] without disclosing that fact in your
> BIP nor
> your pull-req[3].
>
> This is false. The first sentence of the BIP states: "There are incentives
Hi everyone,
Segwit2Mb is the project to merge into Bitcoin a minimal patch that aims to
untangle the current conflict between different political positions
regarding segwit activation vs. an increase of the on-chain blockchain
space through a standard block size increase. It is not a new
but RSK value proposition is "supporting the
advance of Bitcoin, the cryptocurrecy with highest network effect". You
understand that if Bitcoin splits Bitcoin BTC/BTU separately may cease to
be the cryptocurrencies with higher volume/market cap/network effect.
Therefore all RSK people t
Praxelogy_guy,
Yes I understand that segwit2mb represents a "potential" 4Mb block size
increase.
But Segwit does not immediately lead to 2 Mb blocks, but can only achieve
close to a 2Mb increase if all Bitcoin wallets switch to segwit, which will
take a couple of years.
Therefore I don't expect
m for
> testing and implementation.
>
> On Fri, Mar 31, 2017 at 3:13 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> On Fri, Mar 31, 2017 at 6:22 PM, Matt Corallo <lf-li...@mattcorallo.com>
>> wrote:
>&g
o the
> > value it is securing, betting the security of Bitcoin on its price
> > rising exponentially to match decreasing subsidy does not strike me as a
> > particularly inspiring tradeoff.
> >
> > There aren't many great technical solutions to some of these
, 2017 at 11:40 AM, Btc Drak <btcd...@gmail.com> wrote:
> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> The hard-fork is conditional to 95% of the hashing power has approved the
>> segwit
s, the limits of miner "voting" and
the quorums we can expect.
Regards,
Sergio.
>
> On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
>> On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoi
BIP: TBD
Layer: Consensus
Title: Inhibiting a covert optimization on the Bitcoin POW function
Author: Sergio Demian Lerner
Status: Draft
Type: Standards Track
Created: 2016-04-07
License: PD
==Abstract==
This proposal inhibits the covert use of a
The BIP has been updated.
Changes:
- The technical spec has been improved: now the block size increase is
specified in terms of weight and not in terms of bytes.
- The increase in the maximum block sigops after HF has been documented.
- Comments added about the worst case block size.
Happy
ors to try and
> gain more support (not limited to, but including approaching company
> investors to twist arms and veiled threats of blacklisting companies from
> further funding/collaboration).
>
> I think the best you can hope for this hard fork proposal is for it to be
&g
Hello,
Here is a BIP that matches the reference code that the Segwit2x group has
built and published a week ago.
This BIP and code satisfies the requests of a large part of the Bitcoin
community for a moderate increase in the Bitcoin non-witness block space
coupled with the activation of Segwit.
Well, 40 bytes reduction per input is excessive too :)
But 30 bytes reduction will do fine.
On Thu, Jul 13, 2017 at 12:10 AM, Sergio Demian Lerner <
sergio.d.ler...@gmail.com> wrote:
> Some responses..
>
>>
>> The proposal adds another gratuitous limit to the system: A maximum
>> transaction
Some responses..
>
> The proposal adds another gratuitous limit to the system: A maximum
> transaction size where none existed before, yet this limit is almost
> certainly too small to prevent actual DOS attacks while it is also
> technically larger than any transaction that can be included today
November, then for the next Segwit attempt I would choose a more
conservative 50% discount.
On Tue, May 9, 2017 at 12:45 PM, Johnson Lau <jl2...@xbt.hk> wrote:
>
> > On 9 May 2017, at 21:49, Sergio Demian Lerner via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
Jaja. But no shit. Not perfect maybe, but Bitcoin was never perfect. It has
always been good enough. And at the beginning it was quite simple. Simple
enough it allowed gradual improvements that anyone with some technical
background could understand. Now we need a full website to explain an
Let n be the non-segwit bytes. Let the seg/noseg ratio be 1.7.
Segwit with 75% discount: (let WITNESS_SCALE_FACTOR=4)
n*WITNESS_SCALE_FACTOR+n*1.7 = 4,000,000
Then n=4,000,000 / 5.7 = 701K
Average block size = 701K*(1+1.7)=1.8 Mbytes
Maximum block size = 4 MBytes
Segwit with 50% discount + 2MB
>
>
>
> You suggested "If the maximum block weight is set to 2.7M, each byte of
> non-witness block costs 1.7", but these numbers dont work out - setting
> the discount to 1.7 gets you a maximum block size of 1.7MB (in a soft
> fork), not 2.7MB.
Yes. In a soft-fork is true.
I was thinking about
I agree with you Matt.
I'm artificially limiting myself to changing the parameters of Segwit as it
is..
This is motivated by the idea that a consensual HF in the current state
would have greater chance of acceptance if it changes the minimum number of
lines of code.
On Tue, May 9, 2017 at 5:13
es a guideline on how much capacity is gained
> through a particular discount. With the data you show, it would imply that
> those blocks, with SegWit used where possible, would result in blocks of
> ~1.8MB.
>
>
>
> On Mon, May 8, 2017 at 5:42 PM, Sergio Dem
I'm not advocating. I'm mediating.
This is out of
On Wed, May 10, 2017 at 1:39 PM, Matt Corallo
wrote:
> I highly disagree about the "not shit" part. You're advocating for
> throwing away one of the key features of Segwit, something that is very
> important for
I'm a bit late to this party. I just want to add that there exists an
hybrid model where both a federation and the miners provide acknowledges
(sometimes known as "votes" in drivechain terms and "multi-signatures" in a
federation) of the sidechain state.
My Drivechain proposal (Feb 2016) was
Currently the only implementation that fulfills the requirements of the NYA
agreement is the segwit2x/btc1 implementation, which is being finalized
this week.
Segwit2mb does not fulfill the NYA agreement.
I'm asking now the segwit2x development team when a BIP will be ready so
that Core has the
I don't see LukeJr 2MB limit to be compatible with the NY agreement. For
the rest, seems fine for me.
On Fri, Jun 2, 2017 at 4:13 PM, Jared Lee Richardson via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > The above decision may quickly become very controversial. I don't think
I have processed 1000 blocks starting from Block #461653.
I computed several metrics, including the supposed size of witness data and
non-witness data (onchain), assuming all P2SH inputs/outputs are converted
to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
This takes into account
A full node provides several services to the network:
1•Broadcasts blocks (public service)
2•Broadcasts transactions (public/private service)
3•Increases privacy by hiding other node’s IPs
4•Increases network security by protecting it from global DoS.
5•Provides information filtering services to
this soon.
On Mon, May 8, 2017 at 6:44 PM, Natanael <natanae...@gmail.com> wrote:
>
> Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
>
> I'll soon present a solution to encourage full nodes to
>
> There are other solutions to this problem that could have been taken
> instead, such as committing to the number of items or maximum size of
> the stack as part of the sighash data, but cleanstack was the approach
> taken.
The lack of signed maximum segwit stack size was one of the
But generally before one signs a transaction one does not know the
signature size (which may be variable). One can only estimate the maximum
size.
On Fri, Sep 22, 2017 at 6:11 PM, Mark Friedenbach
wrote:
>
> On Sep 22, 2017, at 1:32 PM, Sergio Demian Lerner <
>
If the variable size increase is only a few bytes, then three possibilities
arise:
- one should allow signatures to be zero padded (to reach the maximum size)
and abandon strict DER encoding
- one should allow spare witness stack elements (to pad the size to match
the maximum size) and remove
Historically people have published vulnerabilities in Bitcoin only after
>80% of the nodes have upgraded. This seems to be the general (but not
publicly stated) policy. If you're a core developer and you know better,
please correct me.
This means that:
- a critical vulnerability, like a remote
Hi Peter,
We reported this as CVE-2017-12842, although it may have been known by
developers before us.
There are hundreds of SPV wallets out there, without even considering other
more sensitive systems relying on SPV proofs.
As I said we, at RSK, discovered this problem in 2017. For RSK it's very
Yo can fool a SPV wallet even if it requires a thousands confirmations
using this attack, and you don't need a Sybil attack, so yes, it impacts
SPV wallets also. The protections a SPV node should have to prevent this
attack are different, so it must be considered separately.
It should be said
Also it must be noted that an attacker having only 1.3M USD that can
brute-force 72 bits (4 days of hashing on capable ASICs) can perform the
same attack, so the attack is entirely feasible and no person should accept
more than 1M USD using a SPV wallet.
Also the attack can be repeated: once you
When we worked on the extensions for RSK merge mining, I prepared an
internal document with the most up to date Straum protocol description I
could get.
This is the document:
https://docs.google.com/document/d/1ocEC8OdFYrvglyXbag1yi8WoskaZoYuR5HGhwf0hWAY/edit?usp=sharing
Regards
On Fri, Feb 9,
Hi,
While fixing RSK's SPV bridge I came up with an idea to fix the
MERKLEBLOCK command to prevent rogue peers from attacking SPV peers using
Bitcoin's Merkle tree structure flaws. The most annoying attack is the one
that tries to confuse a victim peer into thinking a transaction is an inner
Hi,
While fixing RSK's SPV bridge I came up with an idea to fix the
MERKLEBLOCK command to prevent rogue peers from attacking SPV peers using
Bitcoin's Merkle tree structure flaws. The most annoying attack is the one
that tries to confuse a victim peer into thinking a transaction is an inner
Seems to be comparable to the proposed "Tick Method" from 2013:
https://bitcointalk.org/index.php?topic=307211.msg3308565#msg3308565
However I remember that someone told me the tick method had a flaw..
On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev <
Hi Roben,
It's an interesting proposal, but I have two issues with it, one technical
and one philosophical.
On the technical side, I don't understand how your proposal prevents miners
proposing a peg-out for an invalid sidechain fork which is not made
available to the nodes (there are missing
Hi Yuri,
While not exactly the same, the idea of using Lamport chains was analyzed
circa 2012 in the context of cryptocurrencies.
I proposed a new signature scheme called MAVE [1], and then a
cryptocurrency scheme called MAVEPAY [2] to reduce the size of signatures
to a minimum of 3 hash
72 matches
Mail list logo