From dreamwvr at dreamwvr.com  Sat Jan  6 09:10:36 2018
From: dreamwvr at dreamwvr.com (dreamwvr)
Date: Sat, 6 Jan 2018 02:10:36 -0700
Subject: [Lightning-dev] rfc using payment_hash fields txn vs the others
Message-ID: <20180106091035.GA29041@dreamwvr.com>

Subject: Re: [Lightning-dev] rfc using payment_hash fields txn vs the others
Reply-To:  dreamwvr <dreamwvr at dreamwvr.com>
 
In-Reply-To: <20180105095541.GA6376 at dreamwvr.com>



On Fri, Jan 05, 2018 at 02:55:41AM -0700, dreamwvr wrote:
> 
> Hi,
> The donation payment_hash txn field layout is diff 
> in the second lines stanza. Instead it goes right to the 
> bes32 static int. Why is does it not use say a 0x20
> to indicate not a bc value or reserved value to indicate
> no bc value in txn?
> 
> would it not simpify optimizing for any sort of deep inspection?
> lnbc <- network to mainnet field
> 1 <- bes32 field
> 1234567 <- epochtimestmp
> (..)
> 
> the rest layout their fields like..
> lnbc <- network to mainnet field
> bcvalue <- some bc value
> 1 <- bes32 field
> (...)
> 
> simplified with a..
> lnbc <- network to mainnet field
> none_bc_value <- reserved hex value says this is hash_payment
> 1 <- bes32
> (...)
> 
with the rfc donation example with the
lnbc <- network to mainnet field 
_second_field_ <- say some reserved hex value for hash_payment
1 <- bes32 
(...)
now if _second_field_ is added like all the others then there is say
potential to add bid on item value using bc value. Since a bid does
not mean in auction that a buyer gets to purchase on a item. It just
says they bid on it. so if there is a..
lnbc <- network to mainnet field
_second_field_ <- either bc value or reserved hex indicates either
                  donation where another reserved hex value indicates
                  secured bid on an item a buyer wants to acquire?
1 <- bes32
(...)
another semi random thought.
Best Regards,
dreamwvr at dreamwvr.com