Topic: NXT :: descendant of Bitcoin - Updated Information - page 1585. (Read 2761647 times)

Ripple has what they call a bitcoin bridge. If someone could implement the equivalent functionality as a reference, then all participating Asset issuers could support the bridge function. This allows someone with a BTC colored coin to send real BTC to any actual bitcoin address. It is not a well known, but super useful function in ripple.

How we can enforce that each and every issuer honors the bitcoin bridge? It devolves to the trust issue again. The "hit by a bus" scenario needs to be solved when significant funds are involved.

We can verify BTC deposits, audit against issued assets, but server outages and other unexpected things happen.

OK, here is a crazy idea. We have 6 million unclaimed NXT that is unallocated. What if the community decides that it is really important to have a trusted BTC asset? What if the community decides to create a community backed BTC asset? What if there was 6 million NXT providing collateral for BTC insurance in case of "hit by bus" scenarios?

Using automation as much as possible to reduce the chances of anything going wrong. multisig BTC accts, whatever, but then the unclaimed NXT or large stakeholder collateralizes a NXT-DIC (FDIC equivalent)? Sounds centralized and probably totally offbase, just trying to think outside the box here.

James

Aye, we don't need too many myths. The Bible 2.0 shouldn't be very thick, leave some room for picture, kids don't like to read walls of text.

I said I own 5M? U r wrong, I said I owned 5M.

Empty blocks are blocks without transactions. More transactions - less empty blocks.

it is kind of silly that there are empty blocks. one would think that forgers would wait until there was atleast 1 transaction before having any reason to forge a block. but i guess thats not the way the client is written and it Isn't worth anyones time to mess with it.

So what causes the empty blocks and will there always be so many?
Because then the description of the likelihood to forge a block i'm sure is correct, but the likely hood of a reward from that is 25%  
based on my current experience.

I would think this belongs to higher level.
Payments are supported. Subscription is regular payments, but there also needs to be support for adding/changing/removing subscriptions, all this is totally application specific.

wesleyh has some code that deals with payments and I would think building a subscription service on top of that would make sense

James

Right. There are still many empty blocks on network.

What trust metric? The issuer of 1 gateway could demonstrate that he owns a large stake (POS) in the NXT system anyway.

I'm wondering how the need for trust can be removed from these gateways.

At least if there were a bunch of decentralised BTC/NXT gateways they have the same common reserve currency (NXT tokens) so they could trade between each other. This could ultimately ensure that "One BTC Coloured Coin = Another BTC Coloured Coin".

Last night a few developers and myself where brainstorming on the concepts of implementing Nxt into e-commerce applications and one use does not seem to be possible.

I do not believe this question has been asked yet, but since Nxt is to be used as a currency, I think there is one use we have yet to touch upon.

Recurring payments? Since Nxt will not only be used for purchasing, but I'm sure for services, many of which will be subscription based, how, if it all, will this be possible? Will this be a function of the client? Is this built into the framework already?

I am personally not interested at all in a site where I can only pay in Fiat using Skrill.

What NXT needs is large exchanges, Cryptsy and alikes. Cryptsy's feature of allowing to trade in USD is coming soon. DGEX was/is a good start despite all the criticism it has received over the past weeks.

CfB just want girls

1. Java is one of the most popular languages (#1 if u need to create a cross-platform solution).
2. Jetty is one of the most popular webserver (used by Google in its app cloud service)
3. This is how all jar-packed applications r ran
4. This is standard place in Jetty

Looks like a good excuse to me, doesn't it?



Really? Ok, each day I study more and more nuances of English. It's not my mother tongue, sorry if sometimes I use incorrect words.

Apologies if this is answered already but i've been following this since page 10 and I can't remember...

I've forged four blocks so far according to the block chain, I received a fee of 4 NXT for the first block I forged and ZERO for the other 3 - is this right?

If every transaction has fees then how can a block reward be zero or did I somehow forge an empty block or are there unlucky blocks and I've been unlucky 3 times in a row?

[need coffee, somehow quote of colored coin threads and BTC asset fragmentation was dropped...]

Anything is possible. For something like that to work, it would require N participants to all agree to honor each others coins at 1:1

For example, the people that end up with the asset names: "BTC", "BTC2", "BTCxyx", etc all agree that they will redeem each others BTC for actual BTC.

The only problem is if something goes wrong, eg. issuer of "BTC2" gets hit by a bus. What happens? Everyone with BTC2 redeems it at the other issuers, so now all the participants have a bunch of BTC2, but he is no more. On a small scale, it would work like a group self-insuring, but what if we are talking about 100BTC worth?

I don't think that approach will work at large scales, due to "hit by bus" scenario.

OK, so plan B.

Let us assume there is a group account that holds all the BTC that backs the Assets issued by all the group members and there was a mechanism for deposits and withdrawals to be processed that can be trusted, it could work.

On deposit to any of the BTC variants, actual BTC goes to BTC variant holder, they issue the BTC variant asset and deposit to shared BTC acct.

On withdrawal, anybody that holds any of the BTC variants can redeem it from the shared BTC acct directly using automated mechanism that recognizes all the BTC variants. This side actually seems doable.

The key to make this work is enforcing the "they issue the BTC variant asset and deposit to shared BTC acct". We cannot control when an account issues an Asset. However, we can track in realtime all issued BTC variants and all deposits credited to that variant. Some sort of realtime audit system could then disable withdrawals for any BTC variant that goes out of balance, with associated public message as to the problem issuer's status.

In order to make that foolproof, all participating issuers would need to NOT issue their asset, until there was confirmation of deposit into the shared acct.

So, my long answer, is yes, this is possible, though ultimately boils down to all participants needing to trust the deposit/withdrawal software and all following strict rules of issuing assets.

James

don't understand.
I should fund an account there and hope they will add NXT?

salsacz, please correct you post or you will create one more myth - I am not a full-time developer of any Nxt appication.

Hi salsacz, thanks for your great paper.

BTW, I'm curious that how do you know BCNext is 35+ years old, CfB is 34 years old, and Jean-Luc is 30+ years old and hold PhD? Thanks.

Tie PoS forging power to trust metric.

Yeah, Fuck Dgex..