Vague random stuff to think about

[anon012012]

Hi I'm just an enthusiast and I had some far-out ideas I wanted to share before I forget, if it's of use to anyone.
It's overly ambitious, trying to tackle big stuff, and blurry and probably flawed. I lack time/skill/smarts to get more into it, the technicalities, but I leave that there for the forengers. Then I'll be on my way.

A)

So, I had that idea
It is a 2nd token to trade, in the blocks
If you own X% of it, you receive X% of the generated supply

I'm not sure if and how it can be done, but I'm thinking about 2 static outputs for each address with shares, one coinbase and one stackable, if it makes sense

It is my favorite idea, the abstract distributed money printing press, fancy term but I like it, we just distribute the supply through free market

B)

Anyway what it could also do, is that if we want to remove coins, then it removes X% from the associated wallet.
There could be price stabilization done through creating and removing coins from investors of this 2nd token.
I understand people don't want to create more bitcoins, and even less remove, to manipulate the supply.
I was thinking about maybe combining that with sidechains.

When creating a sidechain, everyone contributing Y% bitcoins get Y% of the subcurrency and also Y% shares of its printing press.
Then it adds and removes coins through the shares, to stabilize. Dynamic supply inside the fixed supply.
I think that's interesting. That's one thing. The problem is price input.

It could be decided in the sidechain contract. I suggest simply a vote by wealth, to elect a tracker IP.
Another possibility is giving extra vote power to those who created the sidechain.
For example imagine if Europe made a sidechain then every country would have a key to vote.
But they don't have to have all the power. It could be half power to creators, and half by wealth.

Also there would be veto, on top of vote.
The effect on supply from price input is delayed for a time, during which we can veto, with the same key as the wallet.

I don't know if vote by wealth can be included in the system.

C)

I had another idea for price input. We could use the block hash as random seed to select from a pool of jury, then pay them to tell the price, but only if they all agree, like Prisonner's dilemma. And the next juries can veto the previous. And veto by wealth if all the pool is corrupt. But it's weaker than a closed system, and it needs something to form the pool and hide the votes until next block. I don't like that idea much, but I keep it in mind, could be useful.

D)

I also had an idea of multidimensional economy running in parallel (phasing). Can't find less fancy words.
For example let's say we do vote by wealth, with amount of coins being the weight of the vote.
There could be someone with 51% coins trying to harm the currency. So what we do, is that we collectively decide to ignore his account.  
We create a parallel ledger (only the difference is stored, technically) where the coins in his address don't exist anymore. But any transaction done in an economy is done in all compatible economies, it's not totally split.
The disabled account can only spend his coins in the 1st economy. If he sends them to someone, that someone has a warning that says these coins will only be spendable in the first, and maybe it shows a % of how many addresses are compatible.  
It is multidimensional economy, it gives power to the people over the ledger.
When a dimension/phase is created it shows the change, and a description of the reason. It could be more complex than just about accounts.  
There could be entities trusted with judging them, and we auto-follow who we want for convenience, but if it's abused we can always switch back. The people is the judge.
Basically, we give power to the people over the accounts of the people. It's not centralized, it's democratic. It's my newest idea so it's a bit rough, and maybe not feasable or interesting.

I guess that, even uncentralized, whether the people should have access to the accounts of the people is an ideological debate in itself.
And I guess it'd be answered with a big no, around here. Oh well. Anyway I don't know if it can be done or if it means anything.  

E)

You know what I think Bitcoin is lacking, it's banking contracts, trustless banking, cryptobanking. You think Bitcoin is there to eliminate banking, but you don't really hate banking, you hate the current implementation of the concept. But the concept is fondamental. If Bitcoin had banking contracts, then it would mean something different, even though it would be the same protocol. Banking is a protocol to trade instantly between peers who trust a 3rd party, by lending it ownership. I'll tell you what's the problem currently with Bitcoin. When you send coins to a pseudo-bank or an exchange, you have to GIVE them the coins, give them ownership, because the system lacks what you really mean to do. And what you mean to do, is send coins in their wallet but retain ownership, and that's banking. But you have to give them the coins, because the protocol lacks what you mean to do. Banking means sending coins fast with 2 signatures, but slow with one (prosecution). It means asymmetric multisig, where one party has more power than the other, it's not equal. This is how there should be Bitcoin banking: if the 2 parties sign, then the transaction is instant. If only the owner signs, then the transaction has to have locktime, or it's not accepted. And then people don't have to trust a random peer not to double-spend, they only have to trust the 'bank', the signing entity. And yet we retain ownership of the coins, through the forcing-out mechanism. It's better than current banks because it'd cost less and be more efficient and more configurable and less hampered by law, it could be automated through many websites where you'd configure the way you want it to sign. It could even be hierarchical, with one bank (like the home computer) relaying to the superior 'bank'.

I had another related idea where the bank could have an account which can only withdraw with extra long time and we can prosecute money out from its output by contract if it tried to double-spend. We show proof of double-spend with its 2 conflicting signatures and can claim its outputs.

But I'm thinking that maybe instead of just having contract through script, there could be contract as data along transactions, which limit the power of the script. Because if it's just in the script, then you have to stick with the rules in every transaction, when we could just put the rules in one block then in all subsequent blocks the outputs' script has to follow rules according to the contract, and it's enforced by design, I mean the block is just not valid if one of the transaction within doesn't follow the rules in the pool of contracts. But I don't know if it can be done, or if it's a good idea. Maybe people really want everything to be in script.

F)

The last idea is a type of transaction putting 'proof-of-work' in the script, for in-blockchain timelock, or escrow exit
Basically, the output has a target + data in its script, and to spend it you must supply data2 such that datadata2 hashes under target
Some people would solve it faster than others, but it'll always take some time. So it allows in-blockchain escrow. I wrote it but never used a stack language, so take it with a grain of salt:

The script logic is:
if (check(signPayer) and target > hash(data+data2)) true //escrow safety exit
else if (checkmultisig(...)) true //standard escrow success

I did the code for 2-of-2 but it doesn't matter.
Note: I concatenate data/data2 with (data OP_TUCK 32 data2), not sure about that.
And I use LESSTHAN to compare hash/target, but it's only for integer. Anyway here's the script:

1) In the previous transaction, sending coins in the escrow:

- Right-part ScriptPubKey, with rules to spend:
// IF/ELSE for two spending cases, using op_depth as condition
// Case A: there are 3 left stack items in scriptSig: solution hash + key + sig (for escrow exit)
// Case B: there are 4 left stack items in scriptSig: 0 sigA sigB OP_2 (first part of multisig)

OP_DEPTH OP_EQUAL OP_3 OP_IF // If Case A
   OP_DUP OP_HASH160 <payerPubKeyHash> OP_EQUALVERIFY OP_CHECKSIGVERIFY // check the signature, then discard the 'true'
   OP_TUCK 32 <problemHalf> OP_HASH256 <target> OP_LESSTHAN // check the solution, then end CaseA with lessthan's true
OP_ELSE // Else Case B
   <payerPubKey> <arbiterPubKey> OP_2 OP_CHECKMULTISIG // standard multisig
OP_ENDIF

2) In the current transaction, spending from the escrow:

- Usual ScriptPubKey, giving coins to an address:
OP_DUP OP_HASH160 <hexAddressToPay> OP_EQUALVERIFY OP_CHECKSIG

- scriptSig if spending with the solution:
<solutionHalf> <payerSig> <payerPubkey>

- scriptSig if spending with 2 signatures:
0 <payerSig> <arbiterSig> OP_2


But maybe it's not new or not needed.
Anyway I'm no expert but I hope this was interesting at least in some part to more experienced people.

Goodbye

[1715321225]

1715321225

[1715321225]

1715321225

[1715321225]

1715321225

[1715321225]

1715321225

[anon012012]

Ah, I forgot two

G)

Transaction chains, I heard about it, so maybe it's not new, but maybe it was another idea.

Basically an entity is in charge of building a numbered chain of transactions and can redeem them all in one block, in precise order. So maybe there could be fast and precise in-blockchain exchanges. You sign the chain of previous transactions. The protocol would have to accept this kind of data structure.

H)

I had an idea to make transactions more anonymous, using a sort of hub.
It's an entity with a special kind of transaction too. You sign a promise to make X bitcoins available. Other people do the same. The hub then signs a promise to send coins where you want to send them, using other people's outputs. You sign again if it's correct. And then it's redeemed. The hub is only trusted with the privacy of how it has been switched, but it allows to send coins using each other's outputs, so kinda anonymously.

Goodbye

[anon012012]

Also maybe the hub could be distributed, I mean 10 person sign, and they act as hub one after another until the funds actually move, so to know who signed to send where you'd need all 10 to comply

[anon012012]

I forgot my idea for faster synchronization, it's to add a hash of the ledger itself in the block header, every X block, then we download the difficulty we want, for example the last 20 blocks, check the ledger hash, and there'd be full nodes or 3rd parties websites who supply ledger data + hash to prove the data. Or add the whole ledger instead of the hash, every X block, but it takes more space. edit: later I detail how the ledger hash could be the root of a tree of unspent outputs, so we'd send the user outputs first and the other hashes of the tree, it'd synchronize fast

Now I think it's mostly complete, my semi-amateur perspective to help against all the big problems, I hope any of this is actually helpful, though I'm not holding my breath. Whatever, we do what we can.

Goodbye

[cr1776]

...probably flawed. I lack time/skill/smarts to get more into it, the technicalities...

I think for much of this, that is all quite clear.

This looks like all kinds of centralized hubs, third parties, price stabilization, and the like - all things which are pretty much at odds with the distributed nature of bitcoin which is one main advantage.

Perhaps doing some more research and then revisiting the ideas would be productive, then you can fork the software and find someone to implement things if you so choose. If they are good ideas people will flock to you.

[anon012012]

My experience is that people don't flock to good ideas. Centralization is not evil, it is a tool to use, it's neutral.
You dismissed my 3rd party idea which is checked with a hash like for the MD5 checksum of bitcoin-qt's wallet.
You send bitcoins with a 3rd party wallet on a 3rd party computer through a network managed by a 3rd party.
It doesn't matter. What matters is trustlessness. Anyway, I don't have time to revisit. I'm posting what I have.
I'm a newbie so it's surely useless, think what you will, but be polite and don't build yourself an echo chamber.

[jonald_fyookball]

no one insulted you, i think

anyway, if i may offer some friendly advice...

I think if you want to avoid an "echo chamber",
you should post less at a time.

Personally I come here for fun, I don't want to
read 18 paragraphs...too much effort.

try just posting one idea at a time
and maybe we can get a discussion. 

[anon012012]

Alright, I may have been too harsh. I tend to judge too fast, I removed. Sorry, cr1776. Nothing is black or white. You were a bit rough but it's minor and some of your white might be brighter than mine, I don't know you, so I can't judge you really, I was just making a neurotic fuss, maybe paranoidly. I appreciate you contribute and cared enough to give feedback. It makes me think it's all the feedback I'll have. Oh well. And of course we're both human vectors. You can dislike me it doesn't matter. Just be kinder. There are hypersensitive people around, with tiring lives and a high sense of justice. I spent a lot of time thinking about Bitcoin just to help against the risks of fiat and the centralized press, while I'm too poor to own a whole bitcoin, and I got handled roughly like that, it's tiring. If my ideas are worthless then at least I encourage you all to be more respectful. It's not good to discourage the shy and weird to contribute, whatever people may think. Because ideas last longer than opinions. Also you should justify yourself more, generally, especially in first post, because people are biased by it. Anyway, I'll leave it at that, I'm tired. Think whatever of my ideas. I noticed a problem with the distributed hub idea today, I had it just before writing and I'm too hasty. Also I'm thinking maybe the press shouldn't be totally on free market, but it's interesting to be able to distribute the supply with a token. The multidimensional economy, I found an use for it, for example there would be a dimension for people who like Education. In the dimension, we artificially inflate the outputs (of the sidechain, not bitcoin) of accounts of Education budget. Then for the people who did that, these coins would exist, but not for people in other dimension. That means that people in Education can spend these coins in businesses and with people who are pro-Education. So it doesn't inflate the money of everyone, only the concerned. There could be a map where it shows businesses who accept this kind of coins. And there could be a dimension Education+2 for the even more generous. Or a dimension war, and only people who want to fund war would consider the extra war coins as something to work for. These are discrete dimensions but I'll try to think of something more fluid. Basically I was thinking that we don't need multiple currencies or whatever, but it should all be one currency which is highly adaptive. This is why I'm thinking we should be open-minded about banking contracts. Because it's better to have banking inside Bitcoin than outside, if people need it. I don't see the cost of having the feature. Either it's useful or it's not. I think compromise is the path. If it's useful to people, they'll just stick to fiat banks, when Bitcoin could totally replace it all. It doesn't have to be forever we can try to figure out instant trustless transactions without 3rd party on the side, if it can be done. Also, I forgot an idea, we could pay in a store without a smartphone or device if Bitpay or whatever makes a daemon program that runs on home PC with the wallet and will sign the transaction when it receives the locking password (then it could return a word/picture you have associated with the merchant in the daemon) then the one-time password, ect... You get the idea. It's not very practical as is, but it's another idea to think about. Well, that's it. Don't mind the drama. Or mind it. Whatever. I'm too tired to be part of it. What matters are ideas. Now I'll leave you alone because there's a high probability I'm not wanted. Frowns all around. I can only imagine the moderator's frown. I don't want to see it. Also you have pretty much all I had to contribute. Far-out unproven ideas, but well it's something. I'd really consider asymmetric multisig, and take a look at the F idea. Spending with data2 such that datadata2 hashes under target. I think that's cool, using stateless work as time for in-blockchain timelock, but maybe it's not new, I'm a 1yo novice to all that stuff and not up to date with the details. Also I'm not sure how to tie the idea to global hashrate, too tired to think these days, these are old thoughts I had on notepad for months. But I'm sharing before I forget just in case it's actually useful, but seems not, it seems I may have some form of grandiosity. On top of all the rest. Oh well.

And thanks for the advice jonald, I'm working on that problem, but I'm out of juice and time as of now.

[anon012012]

Now that it's cleared up I'll just reply appropriately to the criticism before going, I had forgot:

This looks like all kinds of centralized hubs, third parties, price stabilization, and the like - all things which are pretty much at odds with the distributed nature of bitcoin which is one main advantage.

- For the hub idea (I recall it: we sign this new 3-passes transaction: 1st pass we sign off our coins to the hub, fee included, 2nd pass the hub signs coins to where we told it to send them, but using each other's outputs, 3rd pass we sign again. If the 3 passes are valid, it's accepted in the block). To make this transaction it would be done through clients or websites. You'd be organized with other people to sign this special mix of transactions together. When it's all signed it propagates through the network. Clients could organize it peer-to-peer, and there would be multiple websites/servers to organize it unlikely to be taken down all at once, so it's not at odds. Even if everything is taken down temporarily, it's not a big deal, it's just an anonymizing feature which requires no financial trust, only privacy trust. And like I said there may be a way to rethink the concept of hub distributedly, more properly, for also privacy trust, but one thing at a time. Also maybe the 3rd pass is too 'bloating', I'm not sure. If it's a problem there could be a limit of such transactions per block, and they'd compete by fee. Anyway, it's a minor idea, I'm not sure of the usefulness. And maybe these dark wallets solve anonymity, I didn't look into it. I'm not sure I like this idea anymore, too bloaty, unless it's used to send to an anonymous wallet, which transactions are transparent or anonymized differently. But there are already exchanges for that.

- For side-chain price stabilization, it would be done with vote in blocks, so it's not at odds with the distributed nature. There would be a price tracker, but since we could veto its input during the delay, it's not a vulnerability. Unless attackers take down the whole internet during the delay. Even if they do, the effect would be slight and mostly reversible; and there can be countless safeguards. We can even vote to have no input, if people prefer a static supply. Anyway I'm not sure of the feasibility of adding new coins in millions of different addresses at once. But I think it should be doable if the peers agree precisely on how balances are altered. Just to be clear, I agree that Bitcoin itself should stay mostly static as it is and only ever have 21M coins.

- For the fast synchronization idea, we'd rely on 3rd parties to download a ledger which hashes according to the ledger hash put in the block, so we can download the chain in reverse, with the desired difficulty. It's not a vulnerability because there could be multiple such websites, it could be torrented, and it could be a feature of clients so we download the ledger from other peers. I admit I know little of UTXO, it seems the wiki is lacking the information, so I'm not sure about the nature and size of the ledger, and of this ledger hash idea. Maybe if it's too big, hash in a tree fashion the outputs, and send those of interest in priority, like the part with the user balance. We send to the user his unspent outputs and all the hashes required to reconstruct the ledger hash. It should synchronize fast, since it's logarithmic. I think it should work, I like this idea. But I tend to be too hasty, and lazy. There's probably some flaw.

Anyway, even though there is talk of 3rd parties, they are optional and not vulnerabilities. The problem is I'm not sure about the technical feasibility, I don't know the codebase, and don't code much, just had a period thinking about all that for a few months.
So I wanted to share with more professional people here just in case anything is workable. I had almost forgot to come. It seems it may have been better I had. Oh well. Sorry again, cr1776, you stepped on a landmine. I'm explosive these days.
Thanks to the intrepid readers. My favorite. People who read that much can only be good people. haha
And don't mind what I said, we're all estranged brothers, and a few sisters!

Goodbye

Well, I may be checking until it reaches page 2, in case people like some ideas, that there are replies, questions, criticism or whatnot. But I'm happy with my suggestions having just been read and considered. Maybe I'll eventually post one idea more concisely, on the advice of jonald.
I can tell you, I have some very low social skills

I did post the fast synchronization idea here: https://bitcointalk.org/index.php?topic=757110.0