On Thu, Apr 06, 2017 at 01:32:03AM +, Gregory Maxwell wrote:
> On Thu, Apr 6, 2017 at 12:39 AM, Joseph Poon wrote:
> > #bitcoin@freenode:
> > 00:04gmaxwell| lol poon pretending that he isn't complicit in all this
> > stuff.
> >
> > Are you *fucking* serious? Is this how you resolve all p
Ahh, sorry all for this public message. :(
On Wed, Apr 05, 2017 at 05:39:00PM -0700, Joseph Poon wrote:
> #bitcoin@freenode:
> 00:04gmaxwell| lol poon pretending that he isn't complicit in all this
> stuff.
>
> Are you *fucking* serious? Is this how you resolve all problems? I'm
> taking yo
#bitcoin@freenode:
00:04gmaxwell| lol poon pretending that he isn't complicit in all this
stuff.
Are you *fucking* serious? Is this how you resolve all problems? I'm
taking you seriously and having second thoughts and want to make public
commitments to do the right thing without any evidence
Hi Greg,
On Wed, Apr 05, 2017 at 09:37:45PM +, Gregory Maxwell via bitcoin-dev wrote:
> Reverse engineering of a particular mining chip has demonstrated
> conclusively that ASICBOOST has been implemented
> in hardware.
>
> On that basis, I offer the following BIP draft for discussion.
> This
On Wed, Apr 05, 2017 at 11:37:22AM -0400, Greg Sanders via bitcoin-dev wrote:
> I'd appreciate the authors chiming in, but I read the PASDA differently:
>
> 1) If a transaction is mined with a certain bit set, it reserves 700 bytes
> for that particular block.
> 2) In that space, 2 transactions ma
I agree this is an interesting area of transaction malleability to still
consider in the future, and minimization of these areas of malleability
with regards to its impact on the p2p network should be easy to resolve
and (hopefully) well-understood by script writers in the future.
On Tue, Aug 16,
Hi Bryan,
On Thu, Feb 25, 2016 at 07:34:24PM -0600, Bryan Bishop wrote:
> Well if you are bothering to draft up a BIP about that SIGHASH flag,
> then perhaps also consider some other SIGHASH flag types as well while
> you are at it?
I'll take a look at those proposals when drafting the BIP. I thi
Hi Greg,
On Fri, Feb 26, 2016 at 01:32:34AM +, Gregory Maxwell wrote:
> I think to be successful we must be absolutely ruthless about changes
> that go in there beyond the absolute minimum needed for the safe
> deployment of segwit... so I think this should probably be constructed
> as a new s
As Segregated Witness will be merged soon as a solution for transaction
malleability, especially with multi-party adversarial signatures, there
may be an additional use case/functionality which is helpful for
Lightning Network and possibly other Bitcoin use cases. This requires a
new SIGHASH flag i
Hi Peter,
On Sat, Oct 03, 2015 at 04:30:56PM +0200, Peter Todd via bitcoin-dev wrote:
> So we need to make the case for two main things:
>
> 1) We have applications that need a relative (instead of absolute CLTV)
Lightning network needs RCLTV for bidireciontal payment channels without
an explici
On Wed, Aug 19, 2015 at 09:21:36AM -0700, Mark Friedenbach via bitcoin-dev
wrote:
> If anyone feels strongly about this, please speak up.
>
> On Wed, Aug 19, 2015 at 3:37 AM, Jorge Tim??n <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > I repeated my nit on https://github.com/bitcoin/bips
Hi Chris, I don't speak for Peter, but here's my opinion on the matter
anyway.
On Mon, Aug 17, 2015 at 05:44:56PM -0400, Chris Pacia via bitcoin-dev wrote:
> Can you explain how the spv node fails against an attacker with a
> non-trivial amount of hash power where a full node doesn't? To attack an
Very cool! This will certainly help make Lightning Network testable on
the main-chain and permit channels to remain open indefinitely. I'm
looking forward to it.
On Thu, Aug 13, 2015 at 12:06:44PM +0100, Btc Drak via bitcoin-dev wrote:
> // Note that unlike CHECKLOCKTIMEVERIFY we do not ne
Hi Benjamin,
On Sat, Aug 08, 2015 at 02:01:58PM +0200, Benjamin via bitcoin-dev wrote:
> How do you know who is who online?
If a node is not online, then the payment can be cancelled and
re-routed.
> If Alice and Bob want to transact and haven't exchanged keys before
> they need public-key infr
Hi,
On Mon, Aug 10, 2015 at 12:20:36AM +0200, info--- via bitcoin-dev wrote:
> Off-chain transactions, whether it's Lightning or something else,
> potentially extract fees, which may otherwise be paid to miners, if the
> transactions were actually on-chain.
>
> In this context, wouldn't it be con
Hi Hector,
On Sun, Aug 09, 2015 at 09:48:41PM +0100, Hector Chu via bitcoin-dev wrote:
> 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 the locktime decrements by
>
Hi Gavin,
On Sun, Aug 09, 2015 at 06:44:08PM -0400, Gavin Andresen via bitcoin-dev wrote:
> I'd love to see somebody write up a higher-level description of what the
> user experience is like, what communication happens underneath, and what
> new pieces of infrastructure need to get built to make i
17 matches
Mail list logo
