Subject: Re: [Lightning-dev] rfc using payment_hash fields txn vs the others
Reply-To: dreamwvr <[email protected]>
In-Reply-To: <[email protected]>
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,
[email protected]
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
